REMINDER: LEAP SECOND

Tue Jun 23 07:07:25 UTC 2015

Harlan,

Help me understand why there is a serious risk of going back in time. I acknowledge that there is a remote chance of a backstep, but the probability seems very low.

Suppose I disable my NTP service five minutes before a positive leap second occurs, so that no server in my network can query it. These servers will then run on their own internal clocks. Then, five minutes after the leap second, I re-engage NTP. Assuming a high degree of local oscillator fidelity, imagine the clock drift is zero. The result is that NTP will report one second older than the time currently in my server, i.e. exactly five minutes after the 23:59:60 leap second.

Thus even systems, such as Unix, where 23:59:60 does not exist in the UTC implementation, the timestamp the server sees from NTP is not the potentially code-crashing 23:59:60, but a perfectly rational 00:05:01. This is what my server’s NTP client compares with its internal clock of 00:04:59. NTP's target time is in the future, so there is no risk of going back in time. NTP gradually increments the local time to converge on NTP’s time.

In the alternative case of a negative leap second, following the NTP clock discipline algorithm, the NTP client amortizes the one-second reverse jump, specifically in order to avoid setting the clock backward: the local time will be gradually adjusted again via the clock discipline algorithm until local and NTP times converge. Although the offset is more than the 125ms step threshold, stepping a full one second backward is still statistically unlikely.

It may be that I’ve misread the NTP specification in RPC-5905 and its antecedents, as well as the leap second historical records of problems. But the disabling-NTP-prior-to-leap workaround seems to bypass all the documented leap-second live lock hangs and other bugs..

 -mel

On Jun 22, 2015, at 4:06 PM, Harlan Stenn <stenn at ntp.org<mailto:stenn at ntp.org>> wrote:

Doug Barton writes:
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
On 6/19/15 2:58 PM, Harlan Stenn wrote:
Bad idea.

When restarting ntpd your clocks will likely be off by a second,
which will cause a backward step, which will force the problem you
claim to be avoiding.

There are plenty of ways to solve this problem, and you just get to
choose what you want to risk/pay.

You misunderstand the problem. :) The problem is not "clock skips
backward one second," because most of the time that's not what
happens.  The problem is that most software does not handle it well
when the clock ticks ... :59 :60 :00 instead of ticking directly from
:59 to :00.

POSIX NEVER shows :60.

THAT problem is avoided by temporarily turning off NTP and then
turning it back on again when "the coast is clear." Most software can
handle the "clock skips forward or backwards one second" problem
fairly robustly,= and as Baldur pointed out by doing the reset in a
controlled manner you greatly reduce your overall risk.

Time going backwards is deadly to a number of applications.

But apparently not to applications you care about.

You're also not doing anything where somebody is going to get sued
because a timestamp is off by a second.  There are people for whom this
is a very real risk.

H