[ntp:hackers] smearing the leap second
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
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
(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