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

Terje Mathisen terje.mathisen at tmsw.no
Tue Jan 27 15:58:41 UTC 2015

Jochen Bern wrote:
> 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.

That's correct, in all particulars, and as you note, it basically 
introduces a separate ntp domain for those servers that take part in 
this charade.


- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

More information about the questions mailing list