[ntp:hackers] smearing the leap second

Mike S mikes at flatsurface.com
Fri Jul 10 14:45:47 UTC 2015


On 7/10/2015 10:09 AM, Martin Burnicki wrote:
> Mike S wrote:
>> Ditto, except it is an NTP issue since it only looks like a backward
>> time step because the canonical implementation of NTP doesn't follow its
>> own RFC, and doesn't use a monotonic timescale. If NTP did it right,
>> there wouldn't be any issue.
>
> Nope. On standard installations ntpd just passes the leap second warning
> down to the OS kernel, so the kernel can handle the leap second at the
> right point in time. However, *how* it is handled depends on the kernel.

You say that as if it's true. It isn't. NTP (the implementation) uses a 
timescale which is not monotonic, similar to POSIX. (1) When a leap 
second occurs, NTP (the implementation) steps its timescale back 1 
second. Sure, it passes leap second info, then it goes on to do things 
wrong.

While it claims to count seconds in an epoch (see the RFC, the current 
one started 00:00 1 Jan 1900), it doesn't - it operates in direct 
violation of its own RFC. That's because both NTP (the implementation) 
and POSIX try to do the impossible, both count epoch seconds and assume 
a fixed number of seconds in a day.

It's a very fundamental flaw, trying to do the impossible.

NTP _should_ simply focus on sync'ing epoch seconds with precision and 
accuracy. Then it has no need to handle, or even be aware of, leap 
seconds. Distributing notice of upcoming leap seconds (even though doing 
nothing internally with that info) to a host is a desirable, but 
ancillary function. The actual handling of leap seconds should be a host 
issue, just as conversion from NTP's timescale to the host's timescale 
should be.

(1) see http://www.ntp.org/ntpfaq/NTP-s-related.htm#AEN6768, where leap 
seconds play no part in the calculations.



More information about the hackers mailing list