From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FYUtm-0003wG-Ji for qemu-devel@nongnu.org; Tue, 25 Apr 2006 17:16:42 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FYUtm-0003vn-5C for qemu-devel@nongnu.org; Tue, 25 Apr 2006 17:16:42 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FYUtm-0003vh-2h for qemu-devel@nongnu.org; Tue, 25 Apr 2006 17:16:42 -0400 Received: from [84.96.92.55] (helo=smtP.neuf.fr) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FYUwJ-00051k-Eq for qemu-devel@nongnu.org; Tue, 25 Apr 2006 17:19:19 -0400 Received: from [84.102.211.96] by sp604004mt.gpm.neuf.ld (Sun Java System Messaging Server 6.2-5.05 (built Feb 16 2006)) with ESMTP id <0IYA008FZQVE3T90@sp604004mt.gpm.neuf.ld> for qemu-devel@nongnu.org; Tue, 25 Apr 2006 23:11:38 +0200 (CEST) Date: Tue, 25 Apr 2006 23:10:51 +0200 From: Fabrice Bellard Subject: Re: [Qemu-devel] [PATCH] Timer/clock for Linux In-reply-to: <20060425001645.GA9761@mail.shareable.org> Message-id: <444E905B.5050703@bellard.org> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: <001501c65dd6$484d7c60$0464a8c0@athlon> <444D4603.6090007@bellard.org> <20060425001645.GA9761@mail.shareable.org> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Jamie Lokier wrote: > Fabrice Bellard wrote: > >>Can other people confirm that it is better to always use /dev/rtc on >>Linux ? Is there a way to get the real resolution of the host timer ? > > > Yes, on recent Linux kernels you can do > clock_getres(CLOCK_MONOTONIC,&ts) [or CLOCK_REALTIME], and it will > return the length of a timer tick. On my kernel it's 4.00025 ms. On > other x86 kernels it can be ~10ms or ~1ms. > > Also the recent Linux kernels (more recent) offer "high-resolution > timers"; you can guess what that means. They should be more accurate > than /dev/rtc when they're available, because they reprogram the timer > chip, though I have never tried them. I'd guess that kernels > featuring them would return a small value from clock_getres(). Using clock_getres() seems a good idea if I can test that it is supported. If it is not supported then /dev/rtc will be used in any case. > It's unfortunate that even on kernels where the kernel tick time is > 1ms, setitimer() will cost you a 2ms delay. But: why should that make > Windows run slower? Doesn't qemu read the kernel clock to determine > that the guest is due approx. 2 timer interrupts for each host wakeup? > Naturally you can't let that count increase indefinitely, if the > emulator is too slow to run the guest at full speed, but it might be > an idea to count up to a small number, so that short pauses in host > kernel scheduling won't cause a guest to lose time. QEMU reads the clock at each host wakeup, but it cannot compensate if the guest OS requires a higher frequency than the host timer frequency. Having a 1 ms period is definitively better to be able to run a wide range of guest OSes. Fabrice.