On Sun, 15 Jan 2012, Andrew Worsley wrote:
Any suggestions on logging more info to find the cause or deeper insights into what is going wrong would be appreciated.
More logs with these settings: logfile /var/log/ntpd statsdir /var/log/ntpstats/ statistics loopstats peerstats clockstats filegen loopstats file loopstats type day enable filegen peerstats file peerstats type day enable filegen clockstats file clockstats type day enable (don't forget to logrotate!) Probably won't show anything other than time went off by a small amount.
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 ???
config(1)# ntpq -c rl associd=0 status=c618 leap_alarm, sync_ntp, 1 event, no_sys_peer, version="ntpd 4.2.6p2@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
It thinks it's in error by 16s???
config(0)# ntpdc -c kerninfo pll offset: 0 s pll frequency: 500.000 ppm maximum error: 16 s estimated error: 16 s status: 4041 pll unsync mode=fll pll time constant: 10 precision: 1e-06 s frequency tolerance: 500 ppm
warrane.connect.com.au (192.189.54.33) got dodgy hardware? (do a check_ntp from your host against another ntp server perhaps, then compare against warrane.connect.com.au). ntptrace show anything? Writing a DVD just before? DMA accidentally turned itself off? -- Tim Connors