Keir, Dan:
This is an update on the hpet work. With limited testing, the accuracy
of this method appears to be at least 10 times better than the
pit/tsc method for usex loads. Also, as mentioned before, it does
not have the time going backwards problem. Another interesting property
is that the same policy is used for a 32 bit Linux guest and 64 bit Linux.
Two recent 14-16 hour tests were run, one with usex e48 and the other with
usex b48 as loads. The same load was run on three 8 vcpu guests on an 8 cpu
platform. No ntpd running. ntpdate -b used for initial setting of clock and
ntpdate -q used for monitoring drift. The guests were 4u464, 4u564, 4u432
Linux. The results are:
test duration drift (secs) 4u464,4u564,4u432 drift %
usex b48 16 hrs -.68, -.60, -.68 -.0012
usex e48 15 hrs -.58, -.55, -.58 -.0011
The drift with pit/tsc as checked in reported a few months ago:
The error tests confirm the equivalence. With overnight cpu loads,
the checked in version was accurate to +.048% for sles
and +.038% for red hat.
Recall that .05% is the goal for accuracy so that ntpd can synchronize.
With pit/tsc we are rather close to that limit. So far, with hpet,
we are well under that goal.
As for the code structure, I tried layering on vpt.c and had trouble
doing so. Therefore, I focused on a direct approach. I'll describe the approach
shortly, after I run tests with other loads and guests.
Regards,
Dave
Keir Fraser wrote:
On 26/2/08 14:45, "Dave Winchell" <dwinchell@xxxxxxxxxxxxxxx> wrote:
If this is an integration of hpet into the vpt.c infrastructure then that
would be very welcome.
So far it is not, however I may head in that direction.
Last night's test had an error of .065% on one guest so I still have some
work to do.
Then I hope that the accuracy improvements have come from a set of changes
whose effects are both explicable and generally for the good (rather than
artefacts of how a particular sub-point release of Linux drives the HPET).
-- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home