[ntp:questions] Leap second to be introduced in June
terje.mathisen at tmsw.no
Wed Jan 14 14:58:46 UTC 2015
Jochen Bern wrote:
> On 01/13/2015 09:33 AM, Terje Mathisen wrote:
>> I hate to admit it, but I'm starting to believe Google's approach, where
>> they smear the leap second over something like a day, [...]
>> For distributed logging you have to use the same method for every single
>> node, but that is the case today as well. :-(
>> I.e. with one domain smearing and another stepping, the times between
>> them will be skewed over the entire smearing period.
> I've been pondering this some more. Isn't the consequence that, for the
> purposes of the NTP protocol, "Googleish" and "non-Googleish" systems
> are *fundamentally incompatible* on the day of the leap?
> As in, when ntpd looks across that divide, there'll be an apparent
> offset in the tenths-of-seconds range for the better part of a day,
> which is long enough that ntpd *will* take corrective action (in a
> default config, a step) on the client side, and thus completely hose the
> client OSes' attempt at dealing with the leap second according to its
> native procedure?
> Shouldn't it be a *requirement* that, however an OS chooses to implement
> a leap second, it must keep the timeframe in which its local clock is
> (likely to be) off the true timescale short enough to not confuse
> timesyncing protocols (with the obvious exception of discrete hard
> syncs, a.k.a. SNTP)?
What Google did was to localize all the required leap handling code to
their internal Stratum 2 servers, and only them:
All lower-level servers and clients will never observe any leap event at
all, this works because they made sure that the smearing take so long
that the maximum frequency offset is well below the 500 ppm ntpd limit.
I.e. with a full day of smearing (86400 seconds) and a cosine adjustment
curve (making sure that the derivatives are smooth, i.e. no frequency
steps!), the maximum frequency offset will be pi / (86400*2) or about
1.82e-5 which is the same as 18.2 ppm.
For clients the key is that even with a maximal polling interval
(normally 1024 seconds), you don't want this offset to be able to drop
out of sync:
18.2 ppm * 1024 seconds * 5 polling periods = 93 ms, i.e. still well
within the 128 ms window, but due to the gradual cosine window
application of the adjustment, all clients will have started to adjust
they frequency well before they got close to this limit.
> J. Bern
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
More information about the questions