Re: (progress on hpet accuracy) and Re: [PATCH] Add a timer mode that disables pending missed ticks

[Dave Winchell <dwinchell@virtualiron.com>]

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@virtualiron.com> 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
>
>
>  
>