Dennis Ferguson wrote:
>While NTP-on-the-wire might replay the :59:59 timestamps over you can
>disambiguate which of these you are getting by noting that timestamps from
>the first time through :59:59 will have the leap second warning set while
>the timestamps from the second time through (i.e. the :59:60 timestamps) won't.
I used to think you'd be able to disambiguate them like that, but the
logs I took of NTP state over the recent leap second show otherwise.
I used the very crude technique of running "ntpq -c rv" in a loop,
and what follows are some choice outputs from my primary machine.
The human-readable times are in UT+1h.
First, bracketing 23:59:59.0 UTC:
associd=0 status=4615 leap_add_sec, sync_ntp, 1 event, clock_sync,
version="ntpd [email protected] Sun Oct 17 13:35:13 UTC 2010 (1)",
processor="x86_64", system="Linux/3.2.0-0.bpo.2-amd64", leap=01,
stratum=3, precision=-22, rootdelay=65.202, rootdisp=77.129,
refid=80.1.253.212,
reftime=d39a10ff.c3550e4e Sun, Jul 1 2012 0:57:51.763,
clock=d39a117e.fff62338 Sun, Jul 1 2012 0:59:58.999, peer=56603, tc=6,
mintc=3, offset=32.011, frequency=35.627, sys_jitter=19.899,
clk_jitter=8.425, clk_wander=7.580
associd=0 status=4615 leap_add_sec, sync_ntp, 1 event, clock_sync,
version="ntpd [email protected] Sun Oct 17 13:35:13 UTC 2010 (1)",
processor="x86_64", system="Linux/3.2.0-0.bpo.2-amd64", leap=01,
stratum=3, precision=-22, rootdelay=65.202, rootdisp=77.129,
refid=80.1.253.212,
reftime=d39a10ff.c3550e4e Sun, Jul 1 2012 0:57:51.763,
clock=d39a117f.00cf2f09 Sun, Jul 1 2012 0:59:59.003, peer=56603, tc=6,
mintc=3, offset=32.011, frequency=35.627, sys_jitter=19.899,
clk_jitter=8.425, clk_wander=7.580
Next, bracketing 23:59:60.0 UTC:
associd=0 status=4615 leap_add_sec, sync_ntp, 1 event, clock_sync,
version="ntpd [email protected] Sun Oct 17 13:35:13 UTC 2010 (1)",
processor="x86_64", system="Linux/3.2.0-0.bpo.2-amd64", leap=01,
stratum=3, precision=-22, rootdelay=65.202, rootdisp=77.144,
refid=80.1.253.212,
reftime=d39a10ff.c3550e4e Sun, Jul 1 2012 0:57:51.763,
clock=d39a117f.ffd96bd3 Sun, Jul 1 2012 0:59:59.999, peer=56603, tc=6,
mintc=3, offset=32.011, frequency=35.627, sys_jitter=19.899,
clk_jitter=8.425, clk_wander=7.580
associd=0 status=4615 leap_add_sec, sync_ntp, 1 event, clock_sync,
version="ntpd [email protected] Sun Oct 17 13:35:13 UTC 2010 (1)",
processor="x86_64", system="Linux/3.2.0-0.bpo.2-amd64", leap=01,
stratum=3, precision=-22, rootdelay=65.202, rootdisp=77.144,
refid=80.1.253.212,
reftime=d39a10ff.c3550e4e Sun, Jul 1 2012 0:57:51.763,
clock=d39a117f.00b55bbc Sun, Jul 1 2012 0:59:59.002, peer=56603, tc=6,
mintc=3, offset=32.011, frequency=35.627, sys_jitter=19.899,
clk_jitter=8.425, clk_wander=7.580
So the clock has jumped back, but the leap flag is still set. You can't
distinguish this output from the one a second earlier. Both have
clock=d39a117f.0 and leap=01. The leap flag doesn't change until a few
hundred milliseconds later:
associd=0 status=4615 leap_add_sec, sync_ntp, 1 event, clock_sync,
version="ntpd [email protected] Sun Oct 17 13:35:13 UTC 2010 (1)",
processor="x86_64", system="Linux/3.2.0-0.bpo.2-amd64", leap=01,
stratum=3, precision=-22, rootdelay=65.202, rootdisp=77.144,
refid=80.1.253.212,
reftime=d39a10ff.c3550e4e Sun, Jul 1 2012 0:57:51.763,
clock=d39a117f.b6f7ba42 Sun, Jul 1 2012 0:59:59.714, peer=56603, tc=6,
mintc=3, offset=32.011, frequency=35.627, sys_jitter=19.899,
clk_jitter=8.425, clk_wander=7.580
associd=0 status=061b leap_none, sync_ntp, 1 event, leap_event,
version="ntpd [email protected] Sun Oct 17 13:35:13 UTC 2010 (1)",
processor="x86_64", system="Linux/3.2.0-0.bpo.2-amd64", leap=00,
stratum=3, precision=-22, rootdelay=65.202, rootdisp=77.159,
refid=80.1.253.212,
reftime=d39a10ff.c3550e4e Sun, Jul 1 2012 0:57:51.763,
clock=d39a117f.b7cc1516 Sun, Jul 1 2012 0:59:59.717, peer=56603, tc=6,
mintc=3, offset=32.011, frequency=35.627, sys_jitter=19.899,
clk_jitter=8.425, clk_wander=7.580
Finally, bracketing 00:00:00.0 UTC:
associd=0 status=061b leap_none, sync_ntp, 1 event, leap_event,
version="ntpd [email protected] Sun Oct 17 13:35:13 UTC 2010 (1)",
processor="x86_64", system="Linux/3.2.0-0.bpo.2-amd64", leap=00,
stratum=3, precision=-22, rootdelay=65.202, rootdisp=77.159,
refid=80.1.253.212,
reftime=d39a10ff.c3550e4e Sun, Jul 1 2012 0:57:51.763,
clock=d39a117f.ff8e6634 Sun, Jul 1 2012 0:59:59.998, peer=56603, tc=6,
mintc=3, offset=32.011, frequency=35.627, sys_jitter=19.899,
clk_jitter=8.425, clk_wander=7.580
associd=0 status=061b leap_none, sync_ntp, 1 event, leap_event,
version="ntpd [email protected] Sun Oct 17 13:35:13 UTC 2010 (1)",
processor="x86_64", system="Linux/3.2.0-0.bpo.2-amd64", leap=00,
stratum=3, precision=-22, rootdelay=65.202, rootdisp=77.159,
refid=80.1.253.212,
reftime=d39a10ff.c3550e4e Sun, Jul 1 2012 0:57:51.763,
clock=d39a1180.006bf8df Sun, Jul 1 2012 1:00:00.001, peer=56603, tc=6,
mintc=3, offset=32.011, frequency=35.627, sys_jitter=19.899,
clk_jitter=8.425, clk_wander=7.580
And here it's back to normal.
So, empirically, the NTP on-the-wire protocol doesn't effectively
disambiguate around a leap second. If you want to set your clock
correctly, you'd be well advised to drop any NTP packet showing a time
that can be interpreted as being in the second before a leap second,
regardless of its leap indicator (but especially if it's set).
-zefram
_______________________________________________
LEAPSECS mailing list
[email protected]
http://six.pairlist.net/mailman/listinfo/leapsecs
