You have to consider that the HPET and TSC are both driven by a separate
PLL that is based of some sort of crystal/oscillator. These are often
not as precise as we'd want them to be. If you do a google with "crystal
oscillator ppm" (or some such), you will find that most of these are
within the 50-100 ppm ranges [these are the guaranteed values, which
probably means that the typical is around 25-50 ppm, much along the
lines of your findings]. If you want more precise crystals than that,
you'll be looking at expensive stuff, and when you want less than around
10 ppm, you're probably looking at temperature controlled ones (aka oven
oscillators). They are both expensive and bulky, and very unlikely to be
found on the motherboard. A 2 ppm, 2MHz clock generator that I know of
from a GSM base station is about 80 x 50 x 50 mm. Not sure how much it
cost, but I'm sure it's much more than the clocks that are on even the
most expensive motherboards.
It's possible (or even LIKELY) that the differences you see between the
AMD and Intel platforms stem from something along the lines of using
different or the same oscillator for different parts of the system. One
way to reduce the clock-drift between different parts (assuming this is
something desirable, and that is a debate of it's own) would be to use
the input to the CPU PLL as an input to the (PLL that drives) HPET. I
know for sure that the AMD chipset clock for HPET is NOT derived from
the same as the CPU clock source. I don't know how Intel has solved
their clocking...
And a note on RDTSC: There's a RDTSCP which is a "serializing"
instruction. It also clobbers, I think, ECX, with the current CPU
number. Standard RDTSC is not serializing, so it can be performed out of
order by several instructions. I doubt that this will cause much of the
error discussed, but it may contribute in a positive or negative way...
--
Mats
> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
> Keir Fraser
> Sent: 29 July 2005 19:54
> To: Ian Pratt
> Cc: xen-devel List; Michael Hohnbaum
> Subject: Re: [Xen-devel] HPET/PIT timer accuracy
>
>
> On 29 Jul 2005, at 19:29, Ian Pratt wrote:
>
> >> We're not relying on TSC synchronisation between CPUs.
> They can run
> >> at different frequencies, stop in deep sleep, and so on.
> But we *do*
> >> want the frequency of each one to be as stable as possible. I'd
> >> expect to get <1ppm stability from a crystal source at constant
> >> temperature, no problem.
> >
> > I'd wager the TSC is stable and it's the HPET that's wandering...
> >
> > We'll probably just have to add more damping on the re-calibration.
>
> I haven't done any further tests to see how low the frequency
> of wandering goes. Perhaps we'll find the platform timer is
> more stable over e.g., 60s periods.
>
> -- Keir
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home