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

Terje Mathisen terje.mathisen at tmsw.no
Tue Jan 27 09:21:44 UTC 2015


Miroslav Lichvar wrote:
> On Mon, Jan 26, 2015 at 06:45:58PM +0100, Terje Mathisen wrote:
>> Miroslav Lichvar wrote:
>>> Here is a test showing error between two clients of a server
>>> smearing.a large offset. With the cosine function you can see a large
>>> spike when smearing started.
>>>
>>> https://mlichvar.fedorapeople.org/tmp/smear_cos.png
>>> https://mlichvar.fedorapeople.org/tmp/smear_sinx.png
>>>
>> This seems wrong!?!
>>
>> First of all, you seem to extend the smearing over a million seconds or so?
>> I.e. 10-15 days?
>
> Yes.
>
>> How large is the adjustment to be smeared out?
>
> 10000 seconds. It was a test to see how useful is smearing when
> bringing an isolated network back to UTC in a controlled manner.

10K seconds in 1M seconds corresponds to a steering rate of 1:100 or 10K 
ppm, i.e. 20 times higher than the maximum ntpd adjustment rate.

How would you expect it to work under those conditions?

>
>> The google cosine approach starts with a derivate of zero and ends the same
>> way, I really can't see how that leads to that huge (more than 128 ms!)
>> spike at the start?
>
> The frequency is changing too quickly at start (2nd derivative is at
> the maximum) and the clients don't have a chance to shorten their polling
> interval to better track the server.
>
> The point is that there are better functions than cosine for this.
>
OK, when the adjustment is way outside the control range for ntpd, then 
you are obviously correct: ntpd, either with or without smearing, is not 
the best tool. :-)

Terje

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



More information about the questions mailing list