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.
Terje
Regards,
J. Bern
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
