Re: [Xen-devel] Re: [PATCH] CPUIDLE: revise tsc-save/restore to avoid big tsc skew between cpus

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

On 13/12/2008 04:01, "Wei, Gang" <gang.wei@xxxxxxxxx> wrote:

>> You don't want a platform source, right? So what does it matter? The more
>> important question is: how much inaccuracy is built in to the existing
>> tsc->ns scale factor compared with real wallclock progress of time? And how
>> easily can that be improved? The fact that PIT may wander relative to HPET,
>> for example.... Who cares?
> 
> In my box, the existing initial tsc->ns scale:
>     .mul_frac=ca1761ff, .shift=-1 (2533507879 ticks/sec)
> and the stable calibrated  tsc->ns scale in nopm case:
>     .mul_frac=ca191f43, .shift=-1(2533422531 ticks/sec)
> Don't you think the inaccuracy is a little big (85348 ticks/sec)? But It is
> not really easy to improve it. I will keep using the existing scale for this
> moment. We can keep looking whether we can find a better way to improve it.

The difference is 33 parts per million. The actual frequency of the timer
crystal will likely deviate from its stated frequency by more than that. I
don't think there's anything you can do here (beyond allowing tsc_scale to
be adjusted periodically by ntp algorithms in dom0).

By the way, c/s 18102 (subsequently reverted) may be interesting for you in
implementing the TSC-and-no-platform-timer mode. I'm not sure how much of it
will really be applicable, but it might be worth a look at least.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel