On 15 January 2012 16:09, Andrew Worsley <amworsley(a)gmail.com> wrote:
I am having periodic ntp synchronisation problems.
Apologies for digging up such an old thread, and thanks for reporting
your eventual success to the list.
This caught my interest whilst trawling the archive, and is unrelated
to the recent leap second, but I've just got a few questions regarding
the root-cause...
<...>
Here's the output of commands when things are
bad:
config(0)# check_ntp_peer -H 127.0.0.1 -w 1.0 -c 2.0
NTP WARNING: Server has the LI_ALARM bit set, Offset 0.210925
secs|offset=0.210925s;1.000000;2.000000;
LI_ALARM apparently means not in sync ???
This is actually the "leap indicator", also verified by the ntpq
output below, (via "leap_alarm" and "leap=11"), designed to notify
clients of an impending leap second; consequently most NTP clients
will exclude that reference as a potential time source.
I'm not even sure why this was set? As the previous leap second was on
Dec 31 2008
config(1)# ntpq -c rl
associd=0 status=c618 leap_alarm, sync_ntp, 1 event, no_sys_peer,
version="ntpd 4.2.6p2(a)1.2194-o Sun Oct 17 13:35:13 UTC 2010 (1)",
processor="x86_64", system="Linux/2.6.32-5-amd64", leap=11,
stratum=3,
precision=-23, rootdelay=95.696, rootdisp=263.117, refid=192.189.54.33,
reftime=d2bccf2f.4854b34f Sun, Jan 15 2012 15:06:07.282,
clock=d2bcd1d6.e9ffea4c Sun, Jan 15 2012 15:17:26.914, peer=16519,
tc=10, mintc=3, offset=0.000, frequency=500.000, sys_jitter=35.804,
clk_jitter=0.000, clk_wander=91.828
As for the frequency error greater than 500PPM (~ 43.2 sec / day),
that's incredibly bad quality clock! (It also wanders pretty badly
too!)
It thinks it's in error by 16s???
config(0)# ntpdc -c kerninfo
<...>
ntptime gives the same info
config(0)# ntptime
ntp_gettime() returns code 5 (ERROR)
<...>
No, it's just not synchronised!
Then mysertiously everything is okay:
config(0)# ntpdc -c kerninfo
pll offset: 0.00998 s
pll frequency: 500.000 ppm
maximum error: 1.6291 s
estimated error: 0.004771 s
status: 0001 pll
pll time constant: 10
precision: 1e-06 s
frequency tolerance: 500 ppm
My leap becomes none (no leap_alarm) and things are ok?
Things are not OK, seeing as "no_sys_peer" flag is still set, you've
still not synchronised... (albeit you seeing an offset at least)
config(0)# ntpq -c rl
associd=0 status=0618 leap_none, sync_ntp, 1 event, no_sys_peer,
version="ntpd 4.2.6p2(a)1.2194-o Sun Oct 17 13:35:13 UTC 2010 (1)",
processor="x86_64", system="Linux/2.6.32-5-amd64", leap=00,
stratum=3,
precision=-23, rootdelay=95.272, rootdisp=983.007, refid=192.189.54.33,
reftime=d2bcd33b.bbc10580 Sun, Jan 15 2012 15:23:23.733,
clock=d2bcd852.ec6be1b9 Sun, Jan 15 2012 15:45:06.923, peer=16519,
tc=10, mintc=3, offset=13.497, frequency=500.000, sys_jitter=7.251,
clk_jitter=4.772, clk_wander=151.809
Aside from the bogus leap indicator, I'm curious as to what;
a) hardware you're using (i.e. cat /proc/cpuinfo),
as a modern chipset's TSC should be immune from CPU throttling
b) kernel parameters you're passing at boot (if any)
in particular any of; clock/clocksource/notsc, noapic/noalpci/acpi
c) pool of ntp servers you have configured, and what options
in particular, any of; burst, iburst, minpoll, maxpoll?
On 18 January 2012 22:24, Andrew Worsley <amworsley(a)gmail.com> wrote:
My problem appears to be solved. It's been nearly
24 hours and ntp is
latched very well - 2-3ms offset all day!
<...>
Are you sure you're actually synchronised? Double-check the output of "ntpq
-p"
I think actually adjtimex may take a while to cause
an
effect so I am not sure if I am waiting long enough or undoing the
effect of the previous one.
Yup, for instance adjtime(2) on standard Linux will _slew_ 0.5ms per second
<...>
It might have worked even simpler if I just followed
the instructions,
stopped ntpd, removed the drift file, and ran ntpdate every 10mins
ntpdate -s -b ntpserver which will set the time instantly
Yup, will use settimeofday(2) to _step_ the clock instead
<...>
Also the above link mentions some interesting issues
about the clock
source - it found the hpet clock source was 10x better than tsc.
e.g. -
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
echo hpet > /sys/devices/system/clocksource/clocksource0/current_clocksource
I haven't tried that because I am very happy with things currently.
<...>
I would recommend using the most accurate system clock available to
you, and if that fails, perhaps increasing the ntp poll interval...
otherwise regulating via adjtimex seems like an unnecessary kludge
(pretty sure I've seen this discouraged somewhere too, probably NTP
doco)
--
Joel Shea <jwshea(a)gmail.com>