[LEAPSECS] NTP disambiguation

[Zefram]

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 4.2.6p2 at 1.2194-o 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 4.2.6p2 at 1.2194-o 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 4.2.6p2 at 1.2194-o 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 4.2.6p2 at 1.2194-o 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 4.2.6p2 at 1.2194-o 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 4.2.6p2 at 1.2194-o 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 4.2.6p2 at 1.2194-o 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 4.2.6p2 at 1.2194-o 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