-----Original Message-----
From: Dave Hart
Sent: Sunday, July 01, 2012 3:18 PM
[]
Your offset graphs tell a slightly more nuanced picture which fits my
expectations. ntpd slewed the clock 1s back over 2s near midnight UTC
as expected, regardless of what its sources told it, because it knew
the leap second was scheduled then. Your logs should show an entry
noting the insertion. Then the GPS-connected sources immediately
showed a +1s offset, and due to the short polling interval and the lag
before the GPS receiver got its head straight, managed to slew away
much that 1s offset. It seems like with cheap GPS receivers, a longer
polling interval might be wise around leap seconds. Or switching to
internet sources to number the seconds while keeping PPS...
- The Windows PCs working from LAN/WAN sources saw no glitch. ntpd
4.2.7p285
Offset graphs:
http://www.satsignal.eu/mrtg/performance_ntp.php
Cheers,
Dave Hart
=======================================================
Dave, thanks for your input. Yes, the "Leap second announcement disarmed"
was logged, although the insertion itself was not logged. On PC Alta, 24
minutes later there was a "HZ 64.102 using 43 msec timer .." logged,
followed by a warning that the clock would have gone backwards by ~1000000
microseconds. I've added the event log text, and a Zip archive of event
log, loopstats and peerstats to the Web page at:
http://www.satsignal.eu/ntp/ntp-events.htm#2012-07-01
My feeling is that for low-cost GPS receivers, the second numbering should
not be trusted for 30 minutes after the leap second and only Internet
sources used (where available). Perhaps this could be achieved by ignoring
the serial input as the "prefer" peer?
Cheers,
David
_______________________________________________
pool mailing list
[email protected]
http://lists.ntp.org/listinfo/pool
