hi,
(should I keep replying to both lists now?)
On Sun, Jan 17, 2010 at 1:33 PM, Keir Fraser <keir.fraser@xxxxxxxxxxxxx> wrote:
> What platform timer does Xen say is initialised during boot?
xm dmesg | egrep -i "timer|clock"
(XEN) ACPI: PM-Timer IO Port: 0x808
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
(XEN) Platform timer is 14.284MHz HPET
(XEN) HPET: 4 timers in total, 3 timers will be used for broadcast
(XEN) mcheck_poll: Machine check polling timer started.
> Possibly Xen's
> 'clocksource=' boot option could be used to select a different platform
> timer exhibiting less jitter.
currently, i have " ... clocksource=xen ... "
on these platforms,
@ non-xen,
uname -a
Linux test 2.6.31.8-0.1-desktop #1 SMP PREEMPT 2009-12-15 23:55:40
+0100 x86_64 x86_64 x86_64 GNU/Linux
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc hpet acpi_pm
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc
i've read "tsc" is a "good thing ..." ...
but, @ xen, i've only,
uname -a
Linux test 2.6.31.8-0.1-xen #1 SMP 2009-12-15 23:55:40 +0100 x86_64
x86_64 x86_64 GNU/Linux
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
xen jiffies
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
xen
i've already tried the apparently only other option, 'jiffies', as a
xen clocksource,
echo "jiffies" >
/sys/devices/system/clocksource/clocksource0/current_clocksource
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
jiffies
service ntp restart
(also tried this experiemtn booting to clocksource=jiffies in grub
conf -- no difference)
but i've noticed no improvement in jitter/offset over time,
assID=0 status=c654 sync_alarm, sync_ntp, 5 events, event_peer/strat_chg,
version="ntpd 4.2.4p8@xxxxxx Mon Dec 28 17:26:30 UTC 2009 (1)",
processor="x86_64", system="Linux/2.6.31.8-0.1-xen", leap=11,
stratum=2, precision=-8, rootdelay=0.000, rootdispersion=10.755,
peer=34524, refid=Qq,
reftime=00000000.00000000 Wed, Feb 6 2036 22:28:16.000, poll=6,
clock=cefe0ad1.036efb16 Sun, Jan 17 2010 14:18:49.013, state=2,
offset=0.000, frequency=-362.896, jitter=568.398, noise=3.906,
stability=0.000
remote refid st t when poll reach delay offset jitter
==============================================================================
+clock.fmt.he.ne .PPS. 1 u 26 64 377 18.351 -1363.2 572.904
+otc2.psu.edu 128.118.2.33 2 u 58 64 377 99.412 -1298.6 575.668
+clock.isc.org .GPS. 1 u 61 64 377 19.111 -1296.8 562.546
+clock.sjc.he.ne .CDMA. 1 u 35 64 377 24.181 -1341.8 561.600
+zorro.sf-bay.or 216.218.254.202 2 u 63 64 377 20.503 -1290.7 565.956
*nist1.aol-ca.tr .ACTS. 1 u 35 64 377 24.571 -1339.8 567.403
and, in both these results, & at initially startup,
assID=0 status=c035 sync_alarm, sync_unspec, 3 events, event_clock_reset,
version="ntpd 4.2.4p8@xxxxxx Mon Dec 28 17:26:30 UTC 2009 (1)",
processor="x86_64", system="Linux/2.6.31.8-0.1-xen", leap=11,
stratum=16, precision=-8, rootdelay=0.000, rootdispersion=0.930, peer=0,
refid=STEP, reftime=00000000.00000000 Wed, Feb 6 2036 22:28:16.000,
poll=4, clock=cefe0842.32f14db2 Sun, Jan 17 2010 13:26:54.198, state=4,
offset=0.000, frequency=-362.896, jitter=5.498, noise=3.906,
stability=0.000
remote refid st t when poll reach delay offset jitter
==============================================================================
clock.fmt.he.ne .PPS. 1 u 17 64 1 20.834 -88.894 3.906
otc2.psu.edu 130.207.244.240 2 u 54 64 1 123.655 -12.796 3.906
clock.isc.org .GPS. 1 u 49 64 1 19.517 -34.400 3.906
clock.sjc.he.ne .CDMA. 1 u 25 64 1 16.966 -76.911 3.906
zorro.sf-bay.or 216.218.254.202 2 u 48 64 1 35.391 -29.823 3.906
nist1.aol-ca.tr .ACTS. 1 u 24 64 1 24.211 -74.151 3.906
-- i see "3.906 weirdness". notice the 3.906's in the jitter
(changes over time) & noise/offset (fixed over time) fields?
looking around on the net, i've found no particular explanation for
this; tbh, it doesn't exactly breed confidence.
> Tbh I don't think we've ever done a detailed analysis of ntp performance on
> Xen before
> -- this is something we might be able to improve.
any help would be appreciated.
thanks.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home