The problem strikes after 22 days (two vcpu, xen_system_time timecounter)
ntpd is unable to sync. If I run it aster a rdate, ntpq -c peers shows
offset quickly climbing to 6000 in a few seconds, then 49000 after a minute.
This is a mess.
I have a test program that calls gettimeofday 1000 times in a row
and count how many time it got the same value. I thought it is a
good measure of the problem.
587 1746147362.737757
37 1746147362.747723
376 1746147362.747724
Switching to clockinterrupt timecounter is even worse: the clock
does not change when called 1000 times in a row.
I tried cpuctl offline 1, no change
cpuctl online 1; cpuctl offline 0 seems to restore clock sanity.
My test shows that gettimeofday now returns a different value on
each call. But ntpd still drifts a lot and is unable to sync.
remote refid st t when poll reach delay offset jitter
==============================================================================
timeserver1 145.238.80.80 2 u 12 64 3 0.344 +32825. 29231.6
timeserver2 192.168.82.20 3 u 12 64 3 3.947 +32827. 28551.0
After reboot, everything is fine again.
remote refid st t when poll reach delay offset jitter
==============================================================================
timeserver1 145.238.80.80 2 u 36 64 1 0.236 -0.119 0.024
*timeserver2 192.168.82.20 3 u 14 64 3 1.487 +0.585 0.133
--
Emmanuel Dreyfus
m...@netbsd.org
