Leap second preparedness

[Dave Hart]

I know, leap second preparedness is like sneeze preparedness to people
who have a life. But if you care about the pending hole in computers'
timeline, in about 2 minutes ntpd systems around the world will begin
announcing leap=01 instead of leap=00. If you are responsible for any
ntpd instances, you might spot check to be sure they are in fact
announcing the insertion a day in advance as intended. This is
particularly important for NTP servers relied upon by others.

If you find a system which is still advertising leap=00, you can
correct it by configuring a leapfile, assuming non-ancient ntpd
versions. See:

http://support.ntp.org/bin/view/Support/ConfiguringNTP#Section_6.14.

If your ntpd is relying upon other NTP servers (that is, is stratum 2
or higher), it will not announce the pending leap second starting
exactly at midnight UTC in a few minutes, but should within a few
polling intervals. With the default maximum interval of 1024 seconds
being about 17 minutes, by 00:34 30-June UTC most systems should have
picked it up that will.

Cheers,
Dave Hart

[David J Taylor]

If your ntpd is relying upon other NTP servers (that is, is stratum 2
or higher), it will not announce the pending leap second starting
exactly at midnight UTC in a few minutes, but should within a few
polling intervals. With the default maximum interval of 1024 seconds
being about 17 minutes, by 00:34 30-June UTC most systems should have
picked it up that will.

Cheers,
Dave Hart

=================================================


If it helps at all, I have a small Windows program called NTPLeapTrace. It
displays the upstream leap indications contributing to a target ntpd's leap
election. Although the same can be done using a series of ntpq queries,
it's easier to enter a server or client name and click. Download here:

http://www.satsignal.eu/software/net.htm#NTPLeapTrace

I've just added a second screen-shot show the expected output under "Leap
Second Today" conditions. I hope the program will be of some help.

Cheers,
David

[A C]

On 6/29/2012 16:57, Dave Hart wrote:
> I know, leap second preparedness is like sneeze preparedness to people
> who have a life. But if you care about the pending hole in computers'
> timeline, in about 2 minutes ntpd systems around the world will begin
> announcing leap=01 instead of leap=00. If you are responsible for any
> ntpd instances, you might spot check to be sure they are in fact
> announcing the insertion a day in advance as intended. This is
> particularly important for NTP servers relied upon by others.

Once it's inserted, I assume the log file will record the event in some way?

[A C]

It appears that my system did not respond well to the leap second.

The GPS has not yet received the leap second notification via the
satellites (it is currently still reporting an offset of 15 seconds).
The leap second was inserted by ntpd according to the leap file and then:

Jun 30 23:59:58 sunipx2 ntpd[271]: 0.0.0.0 011b 0b leap_event
x
Jul 1 00:00:21 sunipx2 ntpd[271]: SHM(0) 961a 8a sys_peer
x
Jul 1 00:00:21 sunipx2 ntpd[271]: 0.0.0.0 0413 03 spike_detect
+1.009783 s x
Jul 1 00:05:09 sunipx2 ntpd[271]: 0.0.0.0 041c 0c clock_step +1.015057
s x
Jul 1 00:05:10 sunipx2 ntpd[271]: 0.0.0.0 0415 05 clock_sync
x
Jul 1 00:05:11 sunipx2 ntpd[271]: 0.0.0.0 c418 08 no_sys_peer
x
Jul 1 00:05:11 sunipx2 ntpd[271]: 184.105.192.247 8014 84 reachable
x
Jul 1 00:05:11 sunipx2 ntpd[271]: 130.207.165.28 8014 84 reachable
x
Jul 1 00:05:17 sunipx2 ntpd[271]: 131.144.4.10 8014 84 reachable
x
Jul 1 00:05:17 sunipx2 ntpd[271]: 66.228.35.252 8014 84 reachable
x
Jul 1 00:05:19 sunipx2 ntpd[271]: 173.160.143.19 8014 84 reachable
x
Jul 1 00:05:26 sunipx2 ntpd[271]: SHM(0) 8024 84 reachable
x
Jul 1 00:05:26 sunipx2 ntpd[271]: SHM(0) 903a 8a sys_peer
x12
Jul 1 00:05:27 sunipx2 ntpd[271]: PPS(0) 8084 84 reachable
x
Jul 1 00:05:27 sunipx2 ntpd[271]: PPS(0) 909a 8a sys_peer


It lost PPS lock because SHM(0) was now reporting a full one second
offset. Eventually ntpd forced the clock steps.

The billboard currently shows that the Internet servers are still a
second behind after the above resync:

o127.127.22.0 .PPS. 0 l 12 16 377 0.000 -7.519
2.663
*127.127.28.0 .GPSD. 4 l 13 16 377 0.000 -3.686
10.446
184.105.192.247 216.218.254.202 2 u 204 1024 1 38.373 -1014.3
0.122
173.160.143.19 131.107.13.100 2 u 196 1024 1 75.144 -1019.4
0.122
66.228.35.252 209.51.161.238 2 u 198 1024 1 112.360 -1010.5
0.122
130.207.165.28 130.207.244.240 2 u 96 1024 1 93.724 -1015.8
4.515
131.144.4.10 65.212.71.102 2 u 101 1024 1 96.809 -1014.8
4.166


Previously the Internet servers were only a few milliseconds offset but
SHM(0) showed +1030 or so seconds offset.

[A C]

On 6/30/2012 17:09, A C wrote:
> It appears that my system did not respond well to the leap second.
>
> The GPS has not yet received the leap second notification via the
> satellites (it is currently still reporting an offset of 15 seconds).
> The leap second was inserted by ntpd according to the leap file and then:
>

>[snip]

>
> Previously the Internet servers were only a few milliseconds offset but
> SHM(0) showed +1030 or so seconds offset.

The GPS finally recovered, reporting the new offset almost eight hours
after the fact. However, ntpd was not happy with this situation at all
during that period. The clock was stepping back and forth by a second
because the GPS disagreed with five Internet servers.

It has settled down again though it appears that one server I use didn't
step its own time. It shows as having a one second offset but that's
not an issue I have to handle.