F-ckin Leap Seconds, how do they work?

Thu Jul 5 17:23:32 UTC 2012

On Wed, Jul 4, 2012 at 17:22 UTC, Scott Howard wrote:
> On Wed, Jul 4, 2012 at 8:50 AM, Jimmy Hess <mysidia at gmail.com> wrote:
>
>> The NTP daemon could still provide a configuration option to not
>> implement leap-seconds locally,  or ignore the leap-second
>> announcement received.     So the admin can make a tradeoff  favoring
>> Stability over Correctness, of _allowing_  the local clock to become 1
>> second inaccurate  for a short time after the rare occasion of a leap
>> second;  and step it or slew the local clock,  eg  include the leap
>> second in the ordinary time correction,  averaged over a period of
>> time instead of a 1 second jump.
>>
>
> Unless I'm mis-reading things, it already does - of sorts.

I hope anyone implementing systems that depend on minutae of leap
seconds does not rely solely on your reading, but actually tests by
inconveniently setting their clock and ntpd leapfile to actually
insert a leap second.

> According to the ntpd website (
> http://www.ntp.org/ntpfaq/NTP-s-algo-real.htm#AEN2499) :

That FAQ is woefully out of date.  http://support.ntp.org/ has more
current information.  The best reference for a given ntpd version is
the html docs included in the tarball for that version.  Some
widely-used versions' html documentation is archived at
http://doc.ntp.org/

> *The theory of leap seconds in explained in Q: 2.4.. In reality there are
> two cases to consider:
>
>     If the operating system implements the kernel discipline described in
> Section 5.2, ntpd will announce insertion and deletion of leap seconds to
> the kernel. The kernel will handle the leap seconds without further action
> necessary.

But exactly how it handles it is up to the kernel.  Linux and FreeBSD
essentially step the clock backward 1s at 23:59:60.0 UTC.  At least
one system (I believe it was NetBSD or OpenBSD) instead stalls the
clock for 1s, though each reading of the clock during that period is
greater than the prior, the delta is microscopic and not related to
elapsed time within that second, but simply preserves ordering of
events.  Dr. Mills attempted to exhort kernel developers to implement
leap seconds while keeping the system time ever-increasing, but that
advice was largely ignored because of implementation difficulty.  For
example, when first considered, NTP kernel extensions had microsecond
precision.  The approach of adding a tiny amount with each reading
would open the system up to problems if apps could read the clock more
than 1 million times during the leap second.  It's also ugly for a SMP
kernel to maintain global state on the last clock reading across
processors.

Most systems offer a monotonic alternative to the wall clock,
typically implemented as an uptime counter in nominal SI seconds
(nominal as defined by hardware, as the monotonic clock is _not_
disciplined by ntpd or affected by steps (setting the wall clock to a
particular value).  Look for CLOCK_MONOTONIC in the documentation of
clock_gettime.  There are also interval-only timer facilities like
timer_settime.  The tools are at hand for those who understand the
implications of clock steps (which can occur under circumstances other
than leap seconds).

>     If the operating system does not implement the kernel discipline, the
> clock will show an error of one second relative to NTP's time immediate
> after the leap second. The situation will be handled just like an
> unexpected change of time: The operating system will continue with the
> wrong time for some time, but eventually ntpd will step the time.
> Effectively this will cause the correction for leap seconds to be applied
> too late.
> *

This is the historic behavior of ntpd, but after years of complaints,
it was changed.  ntpd 4.2.6 and later step the clock backward 1s at
the scheduled insertion if using the daemon loop discipline (as
opposed to the kernel loop discipline).

> Linux does implement the "kernel discipline" (via ntp_adjtime), so the
> first option is what normally happens.  However you can disable this with
> an ntpd config option ("disable kernel") or via ntpdc at which point I'm
> presuming it will fall back to the second option.
>
> The second option still gives you a step, but using the -x option to NTPD
> will slew this step, giving a gradual correction to the 1 second difference.

That is incorrect.  -x is often misunderstood -- it does not disable
stepping entirely, it raises the "step threshold" from 0.128s default
to 600s.  When ntpd synchronizes the clock and determines the offset
exceeds the step threshold, the clock is stepped to the correct time.
So long as you manage to keep your clock within 10 minutes of correct,
-x isn't terribly different from disabling steps, but that's not what
it does.

In particular, when ntpd using the daemon loop implements a leap
second by stepping the clock backward one second, the step threshold
(and hence -x) are not a decision factor -- the step is taken.

Cheers,
Dave Hart