From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FYBEZ-000483-Rr for qemu-devel@nongnu.org; Mon, 24 Apr 2006 20:16:51 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FYBEY-00047E-3H for qemu-devel@nongnu.org; Mon, 24 Apr 2006 20:16:51 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FYBEX-000476-Po for qemu-devel@nongnu.org; Mon, 24 Apr 2006 20:16:49 -0400 Received: from [81.29.64.88] (helo=mail.shareable.org) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1FYBGs-0003dT-V3 for qemu-devel@nongnu.org; Mon, 24 Apr 2006 20:19:15 -0400 Received: from mail.shareable.org (localhost [127.0.0.1]) by mail.shareable.org (8.12.8/8.12.8) with ESMTP id k3P0Gj5h012648 for ; Tue, 25 Apr 2006 01:16:45 +0100 Received: (from jamie@localhost) by mail.shareable.org (8.12.8/8.12.8/Submit) id k3P0GjO4012646 for qemu-devel@nongnu.org; Tue, 25 Apr 2006 01:16:45 +0100 Date: Tue, 25 Apr 2006 01:16:45 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH] Timer/clock for Linux Message-ID: <20060425001645.GA9761@mail.shareable.org> References: <001501c65dd6$484d7c60$0464a8c0@athlon> <444D4603.6090007@bellard.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <444D4603.6090007@bellard.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 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(). 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. -- Jamie