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?
Oh, absolutely!
Nobody should ever be allowed to observe/compare time stamps from google
and non-google systems taken at any point during the smear period.
Since Google is lying, they must be responsible for making sure that no
such timing info ever leaks out.
Terje
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)?
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
