[ntp:hackers] smearing the leap second
martin.burnicki at burnicki.net
Fri Jul 10 20:29:54 UTC 2015
Mike S wrote:
> 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
As I said earlier, by default it *only* passes the leap second warning
to the kernel, and the kernel handles the leap second. The NTP daemon on
the other hand just reads the current system time when it needs to
retrieve transmit or receive time stamps, so once more it relies on the
timekeeping of the kernel. It he kernel has just stepped the time back
at the beginning of an inserted leap second, then ntpd also gets the
stepped back time from it, and sends it to its clients on request.
> 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.
Yes, because it just gets the kernel time, and applies a constant offset
to change the epoch from 1970-01-01 to 1900-01-01 for the time stamps
used in the network packets.
How should ntpd do things right if the kernel who actually does the time
keeping relies on POSIX?
> 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.
So you can just use a 1 PPS source to keep the seconds rollover in sync
but don't care about the absolute time?
> (1) see http://www.ntp.org/ntpfaq/NTP-s-related.htm#AEN6768, where leap
> seconds play no part in the calculations.
Isn't that about NTP to MJD vs. Unix to MJD?
*Both* ignore the leap seconds since otherwise ntpd woulldn't be able to
discipline the system time properly, which is just POSIX' idea of UTC.
I really don't understand what you expect from ntpd, and what this
discussion is about.
More information about the hackers