[ntp:questions] Leap second to be introduced in June

Jochen Bern Jochen.Bern at LINworks.de
Wed Jan 14 14:19:31 UTC 2015


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)?

Regards,
								J. Bern
-- 
*NEU* - NEC IT-Infrastruktur-Produkte im <http://www.linworks-shop.de/>:
Server--Storage--Virtualisierung--Management SW--Passion for Performance
Jochen Bern, Systemingenieur --- LINworks GmbH <http://www.LINworks.de/>
Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt
PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27
Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202
Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel


More information about the questions mailing list