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

Terje Mathisen terje.mathisen at tmsw.no
Tue Jan 27 09:16:24 UTC 2015


Jochen Bern wrote:
> On 01/26/2015 01:03 PM, Terje Mathisen wrote:
>> One of the good points about Google's smear is the fact that they use a
>> half cosine to distribute the offset, which means that they have a time
>> function which is both continuous and monotonic, as well as having an
>> infinite number of defined derivatives, i.e. it is maximally smooth.
>
> I noticed that it lends itself to such properties (even if Googles
> specific implementation fails to do so). However, you pay for it either
> in a long window needed to perform the smear, on in some of said
> derivatives going *way* off their normal values.
>
>> The _huge_ problem with their approach is that they have to make d***
>> sure there will never be any time leaks between their internal smeared
>> timebase and any external UTC/TAI clocks as long as the adjustment is
>> taking place.
>
> 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.

> it weren't announced that NTPv5 will support labelling the actual
> timescale used, I'ld propose that future kernels SHOULD not only accept
> "leap second upcoming" bits from an NTP client s/w, but also hand "leap
> second handling in progress" bits back, so as to allow the s/w to mark
> itself as "unsynced" via NTP until the effects are over.

That is already possible, via the leap bits, i.e. declare yourself 
unsynced if contacted from outside the designated smear region?

Terje

>
> Regards,
> 								J. Bern
>


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



More information about the questions mailing list