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. Dennis Ferguson _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
