At Sun, 04 Feb 2024 14:03:37 -0800, "Greg A. Woods" <woods%planix.ca@localhost> wrote:
Subject: Re: timekeeping regression?
>
> This is a domU running on xenful, the "bad" PE2950, after almost
> 4 days of uptime:
>
> remote refid st t when poll reach delay offset jitter
> ==============================================================================
> *xentastic.local 206.108.0.132 2 u 808 1024 377 0.125 -27.501 18.602
So since then the dom0 on the "bad" machine has drifted way ahead in time:
22:00 [xenful] # uptime
10:00PM up 17 days, 9:43, 3 users, load averages: 0.39, 0.34, 0.20
22:00 [xenful] # ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
xentastic.local 192.75.191.16 3 u 31 64 377 0.005 -378226 28449.7
... and all the other VMs have drifted badly in the opposite direction,H:
19:25 [nbtcur] # uptime
7:25PM up 14 days, 21:28, 1 user, load averages: 0.28, 0.13, 0.04
19:25 [nbtcur] # ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
xentastic.local 192.75.191.16 3 u 500 1024 377 1.205 +572972 404499.
On the "good" machine the dom0 is still A-OK:
11:25 [xentastic] # uptime
11:25AM up 17 days, 20:19, 2 users, load averages: 0.00, 0.00, 0.00
11:25 [xentastic] # ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
local-bcast.loc .BCST. 16 B - 64 0 0.000 +0.000 0.001
0.north-america .POOL. 16 p - 64 0 0.000 +0.000 0.001
1.north-america .POOL. 16 p - 64 0 0.000 +0.000 0.001
2.north-america .POOL. 16 p - 64 0 0.000 +0.000 0.001
3.north-america .POOL. 16 p - 64 0 0.000 +0.000 0.001
ca.pool.ntp.org .POOL. 16 p - 64 0 0.000 +0.000 0.001
0.netbsd.pool.n .POOL. 16 p - 64 0 0.000 +0.000 0.001
1.netbsd.pool.n .POOL. 16 p - 64 0 0.000 +0.000 0.001
2.netbsd.pool.n .POOL. 16 p - 64 0 0.000 +0.000 0.001
3.netbsd.pool.n .POOL. 16 p - 64 0 0.000 +0.000 0.001
+time13.nrc.ca 132.246.11.231 2 u 309 1024 377 63.438 -0.123 0.292
#time2.chu.nrc.c 209.87.233.52 2 u 282 1024 377 91.675 -8.920 14.318
-ntp1.torix.ca .PTP0. 1 u 441 1024 377 53.818 -2.630 0.367
-ntp2.torix.ca .PTP0. 1 u 268 1024 377 55.355 -1.144 2.768
-ntp3.torix.ca .PTP0. 1 u 607 1024 377 55.217 -3.842 0.475
+ntp1.yycix.ca 206.108.0.132 2 u 1000 1024 377 21.049 -0.497 0.379
*ntp2.yycix.ca 10.0.17.1 2 u 225 1024 377 21.547 -0.127 0.383
... and the FreeBSD VM is also OK:
11:26 [fezzik] # uptime
11:26AM up 17 days, 20:19, 3 users, load averages: 1.36, 0.98, 0.91
11:26 [fezzik] # ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*xentastic.local 192.75.191.16 3 u 190 1024 377 0.143 -14.229 17.002
... but one NetBSD VM has drifted significantly:
10:02 [nbtest] # uptime
10:02AM up 17 days, 18:54, 1 user, load averages: 0.00, 0.00, 0.00
10:02 [nbtest] # ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
xentastic.local 192.75.191.16 3 u 1199 1024 377 0.074 +490416 30217.3
> According to some discussions I found on the internets the Xen kernel
> itself could/should now use TSC on systems where TSC is either
> effectively or actually stable across cores (and I think it will
> automatically in certain conditions where TSC is guaranteed safe), and
> so I tried appending "clocksource=tsc tsc=stable:socket" to the Xen
> command line on the two PE2950s, but that didn't seem to change anything
> (i.e. the Xen platform timer stays configured as HPET). The most recent
> Xen code says, as I read it, that it should print a debug message if the
> configured clocksource isn't valid, but even with "loglvl=all" there's
> no such message appearing. More digging and debugging to do. I really
> would like to get Xen using TSC as its platform timer and see if that
> makes any difference.
Still looking for a Round Tuit to do the investigation into why
"clocksource=tsc" isn't taking effect, and it'll have to wait a couple
more weeks now, so if anyone else beats me to it.....
--
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>
Attachment:
pgpgelMNkV41H.pgp
Description: OpenPGP Digital Signature