This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] HPET/PIT timer accuracy

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] HPET/PIT timer accuracy
From: Michael Hohnbaum <hohnbaum@xxxxxxxxxx>
Date: Fri, 29 Jul 2005 11:17:16 -0700
Cc: Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>, xen-devel List <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 29 Jul 2005 18:16:36 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <a5c1701524ff2f80257038d6fdb7fb53@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: IBM LTC
References: <a5c1701524ff2f80257038d6fdb7fb53@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Fri, 2005-07-29 at 18:26 +0100, Keir Fraser wrote:
> Does anyone on this list have an idea of expected accuracy of chipset 
> time sources (e.g., PIT/HPET)? I've been looking at relative frequency 
> stability of the CPU-local TSC and platform HPET on a few different 
> systems, and see weird instabilities that I cannot explain.

The TSC is not a reliable time source.  There is no guarantee of
synchronization between multiple CPUs.  Also note that the TSC will
stop in ACPI C3 mode.  Probably not an issue for Xen today, but could
be in the future, especially as servers start doing more power
management.  The HPET is preferable for a time source on systems 
that this is available on.
> On a couple of systems based on Intel E7520 (Lindenhurst) chipset I see 
> the relative frequency is stable to within a couple of parts per 
> million (which is within measurement error). Either the two are clocked 
> from the same crystal, or two crystals with low frequency drift/wander 
> (but not unexpectedly low -- I don't think crystals should drift over 
> short time periods).
> In contrast, two different systems based on AMD 8111 chipset perform 
> very badly. The relative frequency of TSC vs HPET is stable only to 
> within +/- 30ppm! This means that, during one second, timers based on 
> these two sources can diverge by around 30us, which is a *lot*. Clearly 
> the TSC and HPET are driven off different time sources, but I almost 
> cannot believe that both are driven off crystals -- one of the two must 
> have a 1Hz frequency drift/wander of 30ppm which is totally outside the 
> specs I'd expect of a crystal source.

These types of observations are not inconsistent with what others have
seen.  Very platform dependent.
> Any ideas what could be going on?! This is something of a pain for the 
> new time code, which syncs the local TSCs to the chipset timer....

This is a reality of the various hardware time sources.  There are many
problems associated with this.  You might look at the OLS paper on 
a proposed rewrite for the Linux time subsystem to get a feel for how
the kernel people are trying to deal with some of these issues.

>   -- Keir
> (I am talking frequency stability here, by the way, not frequency 
> tolerance. I know a crystal can be 100s of ppm out of whack from what 
> is stamped on the can, but I think over short time periods it should 
> not drift noticeably from its natural frequency).

Michael Hohnbaum                             503 578 5486
hohnbaum@xxxxxxxxxx                          t/l 775 5486

Xen-devel mailing list