I forgot to ask one other question about critical timing and clock
information: Which platform timer is the Xen kernel selecting?
As far as I know this is only shown in the Xen console output, so:
xl dmesg | fgrep 'Platform timer'
Also for fun what does this show:
xl dmesg | fgrep -i tsc
(I keep meaning to add something to the rc.d script(s) to save "xl dmesg")
> What is suprising is that it happens on a domU but not on another on
> the same dom0.
To me this simply points to problems in the underlying emulation of
RDTSC done by the Xen kernel.
I can now report that with clockinterrupt as the timecounter my dom0 on
the test machine is continuing to keep "close enough" time for ntpd to
stay in sync though it is getting a little more jittery.
# /sbin/sysctl kern.timecounter
kern.timecounter.choice = clockinterrupt(q=0, f=1000 Hz) xen_system_time(q=10000, f=1000000000 Hz) ichlpcib0(q=1000, f=3579545 Hz) ACPI-Safe(q=900, f=3579545 Hz) dummy(q=-1000000, f=1000000 Hz)
kern.timecounter.hardware = clockinterrupt
kern.timecounter.timestepwarnings = 1
# 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.002
+xenful.local 206.108.0.132 2 s 155 512 36 134.264 -618.34 250.992
0.north-america .POOL. 16 p - 64 0 0.000 +0.000 0.002
1.north-america .POOL. 16 p - 64 0 0.000 +0.000 0.002
2.north-america .POOL. 16 p - 64 0 0.000 +0.000 0.002
3.north-america .POOL. 16 p - 64 0 0.000 +0.000 0.002
ca.pool.ntp.org .POOL. 16 p - 64 0 0.000 +0.000 0.002
time.nrc.ca 132.246.11.231 2 u 691 1024 7 0.010 -104.66 396.718
time1.chu.nrc.c 209.87.233.52 2 u 643 1024 7 0.032 -679.32 674.581
ntp1.torix.ca .PTP0. 1 u 671 1024 7 0.029 -438.14 180.117
ntp2.torix.ca .PTP0. 1 u 638 1024 7 0.028 -390.50 357.016
ntp3.torix.ca .PTP0. 1 u 679 1024 7 0.030 -226.13 95.215
ntp1.yycix.ca 206.108.0.133 2 u 642 1024 7 0.002 -470.31 174.804
ntp2.yycix.ca 54.39.196.172 3 u 693 1024 7 0.136 -125.03 340.438
+static.190.111. 225.254.30.190 4 u 675 1024 7 0.014 +188.19 552.482
*x.ns.gin.ntt.ne 129.250.35.222 2 u 599 1024 7 0.015 -707.65 499.440
The two NetBSD domUs have wandered off in time though.
However the FreeBSD domU is currently still keeping time as well, and
with less jitter! It is using "XENTIMER" for both timecounter and
eventcounter (and it doesn't have the option of "clockinterrupt"). It's
reporting a significantly skewed TSC frequency though. I think it just
calculated that itself at boot, so not surprising it got it so wrong.
FreeBSD $ /sbin/sysctl kern.timecounter
kern.timecounter.tsc_shift: 1
kern.timecounter.smp_tsc_adjust: 0
kern.timecounter.smp_tsc: 0
kern.timecounter.invariant_tsc: 0
kern.timecounter.fast_gettime: 1
kern.timecounter.tick: 1
kern.timecounter.choice: TSC-low(-100) XENTIMER(950) dummy(-1000000)
kern.timecounter.hardware: XENTIMER
kern.timecounter.alloweddeviation: 5
kern.timecounter.timehands_count: 2
kern.timecounter.stepwarnings: 0
kern.timecounter.tc.TSC-low.quality: -100
kern.timecounter.tc.TSC-low.frequency: 1579390000
kern.timecounter.tc.TSC-low.counter: 187185924
kern.timecounter.tc.TSC-low.mask: 4294967295
kern.timecounter.tc.XENTIMER.quality: 950
kern.timecounter.tc.XENTIMER.frequency: 1000000000
kern.timecounter.tc.XENTIMER.counter: 3992518617
kern.timecounter.tc.XENTIMER.mask: 4294967295
--
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:
pgpnsFOwXLCh6.pgp
Description: OpenPGP Digital Signature