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

Jochen Bern Jochen.Bern at LINworks.de
Tue Jan 27 14:13:22 UTC 2015

On 01/27/2015 10:16 AM, Terje Mathisen wrote:
> Jochen Bern wrote:
>> Because they chose the long window (about one day) and made it exceed
>> the time an NTP peering needs to *act* on the perceived offset, yes. If
> That's a a key feature of the long adjustment period: The smearing takes
> so long that the frequency offset is never even close to the 500 ppm
> limit, and (since the first derivative is smooth) the change is
> frequency is gradual enough that all the clients will be able to track
> it, even if they are running at a fixed 1024 s polling interval.

OK, but that's assuming that the client will "absorb" the leap second
entirely by having an NTP server dragging it along within the limits of
a normal NTP sync, without *ever* informing the client kernel's leap
second handling routines that one even occurred.

Which means that your client cannot be talking to a normal NTP server
with normal NTP client s/w, and if kernels ever would attempt to keep
track of past leap seconds on their own, *this* client's kernel would
fail in that because it never gets *told* of leap seconds as they happen.

								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