From mboxrd@z Thu Jan 1 00:00:00 1970 From: Beth Kon Subject: Re: [Qemu-devel] [PATCH 1/2] Add HPET emulation to qemu (v3) Date: Mon, 20 Oct 2008 15:08:44 -0400 Message-ID: <1224529724.3399.27.camel@beth-laptop> References: <1224245854.3399.7.camel@beth-laptop> <20081017154932.GA14229@shareable.org> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: qemu-devel@nongnu.org, Alexander Graf , kvm@vger.kernel.org To: Jamie Lokier Return-path: Received: from e1.ny.us.ibm.com ([32.97.182.141]:49442 "EHLO e1.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752322AbYJTTIV (ORCPT ); Mon, 20 Oct 2008 15:08:21 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m9KJ8Jwm016825 for ; Mon, 20 Oct 2008 15:08:19 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m9KJ8IUC128090 for ; Mon, 20 Oct 2008 15:08:18 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m9KJ8IKu031884 for ; Mon, 20 Oct 2008 15:08:18 -0400 In-Reply-To: <20081017154932.GA14229@shareable.org> Sender: kvm-owner@vger.kernel.org List-ID: On Fri, 2008-10-17 at 16:49 +0100, Jamie Lokier wrote: > Beth Kon wrote: > > Clock drift on Linux is in the range of .017% - .019%, loaded and unloaded. I > > haven't found a straightforward way to test on Windows and would appreciate > > any pointers to existing approaches. > > Is there any reason why there should be any clock drift, when the > guest is using a non-PIT clock? > > I'm probably being naive, but with 32-bit or 64-bit HPET counters > available to the guest, and accurate values from the CMOS clock > emulation, I don't see why drift would accumulate over the long term > relative to the host clock. I was measuring with ntpdate, so the drift is with respect to the ntp server pool, not the host clock. But in any case, since timer interrupts and reads of the hpet counter are at the mercy of the host scheduler (i.e., the qemu process can be swapped out at any time during hpet read or timer expiration), I'd guess there would always be some amount of inaccuracy. Also, qemu checks for timer expiration (qemu_run_timers) as part of a bigger loop (main_loop_wait), so the varying amounts of work to do elsewhere in the loop from iteration to iteration would also introduce irregular delays. > > -- Jamie > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Elizabeth Kon (Beth) IBM Linux Technology Center Open Hypervisor Team email: eak@us.ibm.com