[ntp:questions] Leapsecond on FreeBSD or Windows - no showstopper bugs, but ...

Dave Hart hart at ntp.org
Sun Jul 1 16:12:00 UTC 2012


On Sun, Jul 1, 2012 at 09:24 UTC, David J Taylor wrote:
> - The Windows PCs fed from either Garmin GPS 18/x LVC or Sure Electronics
> GPS boards appear to have reset itself some 17..24 minutes after 00:00,
> suggesting they were using the GPS for the time (as well as the precise PPS
> edge), and the GPS devices took some time to reflect the leap-second in
> their serial outputs.  Almanac reload time?   These PCs had the leap-seconds
> file.  Perhaps it would have been better had ntp not believed the GPS serial
> time for the coarse time, but the time coming from other LAN/WAN servers?
> This needs closer investigation.  The reset resulted in a further period
> until normal offset accuracy was restored.  ntpd 4.2.7p285.
>  PCs: Alta, Bacchus, Feenix & Stamsund in the graphs linked below.
>
> - The Windows PCs working from LAN/WAN sources saw no glitch.  ntpd
> 4.2.7p285
>  PCs: Hydra, Molde, Narvik, Torvik & Ystad in the graphs below:

As I mentioned on the pool list, I think there's a bug in the
application of the leap second to the local clock in recent ntpd.
Please check the event log on each of your Windows systems around the
event.  If everything worked perfectly, you'd see mentions both of the
positive leap second insertion occurring, and of the leap indication
being disarmed.  On a system with a GPS+PPS refclock, I saw only the
disarming message, then a naughty -1s step 12.5 minutes later:

30 Jun 23:59:59 ntpd[2272]: 0.0.0.0 041b 0b leap_event
 1 Jul 00:00:00 ntpd[2272]: Leap second announcement disarmed
 1 Jul 00:00:15 ntpd[2272]: 0.0.0.0 0413 03 spike_detect -0.999998 s
 1 Jul 00:03:45 ntpd[2272]: 2001:4f8:fff7:1::17 962a 8a sys_peer
 1 Jul 00:12:29 ntpd[2272]: 0.0.0.0 061c 0c clock_step -1.006282 s

On a system synched to another NTP server, the leap second insertion
(fast slew) happened but there's no message about disarming.  Also
both the leap_event and the insertion are relatively late:

 1 Jul 00:00:33 ntpd[10184]: Inserting positive leap second.
 1 Jul 00:00:57 ntpd[10184]: 0.0.0.0 061b 0b leap_event

There's clearly still work to do.

Cheers,
Dave Hart


More information about the questions mailing list