[ntp:hackers] smearing the leap second

Harlan Stenn stenn at ntp.org
Fri Jul 10 20:06:04 UTC 2015

Mike S writes:
> 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.

I think I disagree with your interpretation.

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

I'll say it again: reality bites.  We can declare that pi is 3 because
that makes the math easier, too.

> 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.

Issues with the leap second are best solved at the lowest-level
possible.  Anywhere else gets more expensive and/or provides worse data.

NTP provides a number of mechanisms to handle the leap second.  These
mechanisms enable folks to implement a good number of local policy
choices about the leap second.

If you want to run your system using GPS time and the posix/right
timezones, goferit.  Same for using POSIX time and letting the kernel or
NTP do its thing.  Same for the leap smear.

A big problem today is that NTP is implemented using cooperating
distributed systems, and if different systems use different timescales
(GPS, smeared, backward step, a slew that starts at who-knows-when) then
there's no way to communicate that with NTPv4 or earlier.

NTF's General Timestamp API can address this, and as soon as we have
resources to make it happen it will get done.  And even when that is
finished there will be a huge number of folks who will still run old
versions of NTP because they don't see any reason to change.

Reality bites.
Harlan Stenn <stenn at ntp.org>
http://networktimefoundation.org - be a member!

More information about the hackers mailing list