[LEAPSECS] NTP disambiguation
dennis.c.ferguson at gmail.com
Tue Jul 10 10:48:36 EDT 2012
On 9 Jul, 2012, at 18:35 , Zefram wrote:
> 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,
Yes, that's the bit I pointed out in the sentences before the quote:
>> The unfortunate thing about the latter is that since ntpd the implementation
>> was a little sleazy and ambiguous about what happened during a leap second,
>> NTP, the on-the-wire protocol definition, was made similarly ambiguous. This
>> did not have to be (as I realized when working through what was necessary
>> to use standard NTP to keep non-POSIX "right" kernel time synchronized).
The NTP on-the-wire protocol definition leaves what happens during a leap second
ambiguous; no particular behavior of the timestamps is specified, and the
documentation which exists suggests it is even acceptable to stop the timestamps
from advancing for a second. ntpd the implementation does whatever the kernel
it is running on does.
You are correct that the best you can do with packets carrying timestamps taken close
to a leap second is ignore them. It didn't have to work that way, however.
More information about the LEAPSECS