Re: timekeeping regression?

[Brad Spencer <brad%anduin.eldar.org@localhost>]

"Greg A. Woods" <woods%planix.ca@localhost> writes:

[off list]

[snip]

> So I pinned them at runtime:
>
> # xl vcpu-list Domain-0
> Name                                ID  VCPU   CPU State   Time(s) Affinity (Hard / Soft)
> Domain-0                             0     0    3   r--     806.0  all / all
> Domain-0                             0     1    2   -b-     715.6  all / all
> # xl vcpu-pin 0 0 0
> # xl vcpu-pin 0 1 1
> # xl vcpu-list Domain-0
> Name                                ID  VCPU   CPU State   Time(s) Affinity (Hard / Soft)
> Domain-0                             0     0    0   -b-     807.9  0 / all
> Domain-0                             0     1    1   r--     716.6  1 / all
>
> And voila!  Instantly no more raw system time going backwards events!
>
> Also ntpd is again able to hold the clock stable again (after a reset
> step by ntpdate).
>
>
> I thought this might be because there's no way (that I know) to set the
> tsc_mode for dom0, but given that the tsc_to_system_mul shown in the
> debug printf is about what it should be to round down to 1GHz on this
> machine then it seems RDTSC must be being emulated.
>
> I guess the RDTSC emulation must not be stable across CPUs?  Or?

This is all very interesting behavior...  I think that there *IS*
something after that second question, the "Or?", however...  I have
three DOM0 systems, one is a very old AMD Athlon II, one is a I7
generation Intel and the other is a I7 or I8 generation Intel.  Not one
of these DOM0 systems has ntpd drift like you are seeing.  I do run them
with a HZ of 1000HZ, but other than that it is a stock DOM0 kernel.

Two of the DOM0s I have do report some of the 'raw systime went
backwards' ... but the number is very small.  I have not updated the
kernels yet to beyond 10.0_BETA on any of them, and most are 9.x, so
there might be something lurking after 10.0_BETA??

> Now I wait some days again to see if the newest xen_clock.c gives me any
> more clues as to why, if it still happens, that domU clocks begin to
> drift after ~7.5 days of uptime.....

The drifts and instability I have seen with respect to time have always
been in the DOMUs, especially pure PV DOMUs with more than one vcpu.

I suppose the 7.5 days of uptime could not be due to a cron job that
happens to run at about that time??

> --
> 					Greg A. Woods <gwoods%acm.org@localhost>
>
> Kelowna, BC     +1 250 762-7675           RoboHack <woods%robohack.ca@localhost>
> Planix, Inc. <woods%planix.com@localhost>     Avoncote Farms <woods%avoncote.ca@localhost>


I am very glad you found something out about this problem.






-- 
Brad Spencer - brad%anduin.eldar.org@localhost - KC8VKS - http://anduin.eldar.org