Re: timekeeping regression?

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Tue, Jun 18, 2024 at 09:11:50PM -0400, Brad Spencer wrote:
> "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??

I have several Xen servers, but all running on Intel Xeon CPUs
(of various models). I have no issues with time in dom0 or domUs ...

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--