[ntp:hackers] First sample after f15 minutes used. Really?

David L. Mills mills at udel.edu
Sun Sep 9 20:44:16 UTC 2007


Brian,

You might misunderstand the purpose of the scheme. First, the mitigation 
is done before the threshold is checked, so presumably we have the best 
candidates to wiggle the clock. Although a rogue sample or two might 
exceed the step threshold, it's highly likely a good sample will come 
along and reset the stepout counter.

You properly observe that at poll intervals longer than 900 s the 
selection window is not effective. The strategy to deal with spikes now 
becomes an integration issue, as the time constant has become very long 
- as long as 36 h. However, by recommendation, burst mode should be used 
when the poll interval is expected to be large, so that fixes the problem.

There were two scenarios that prompted this design. In the bad old days 
the lines to Norway and Italy were really awful, with spikes over one 
second, but the spikes came in surges lasting less than a minute. The 
design is ideal for situations like that, as it results in little holes 
in synchronization that cause no disruptions. Another scenario that 
applies to me is slow ISDN links where traffic is mainly in bursts with 
offsets large fractions of the second.

You might ask why 900 s? The answer has to do with radio clocks that 
don't anticipate leap seconds. On several occasions when a leap occured 
the radio had to resynchronize after the leap. The kernel had taken the 
leap as advised, but, because of the 900-s wait, left that time for the 
radio to resynchronize properly.

You might be assured the popcorn spike suppressor, clock filter, stepout 
algorithm and sample selector work as intended either in siumlation or 
in vivo using raw timestamps in the filegen data. Real world results are 
in the book.

Dave

Brian Utterback wrote:

> To answer my own question, the wording isn't exactly right. What 
> happens is that any offset greater
> than 128ms is ignored for 15 minutes. If it has been over 15 minutes 
> since the last clock update, then
> the offset (Still calculated by the normal method) is allowed. So, the 
> standard clustering and combining
> is still in effect.
>
>
> Brian Utterback wrote:
>
>> (Resending, including Dave this time.)
>>
>>
>> In the documentation for ntpd, it says:
>>
>>  
>>
>>> The ntpd  algorithms  discard  sample
>>>      offsets  exceeding  128 ms, unless there is no sample offset
>>>      of less than 128 ms for 15 minutes. The first  sample  after
>>>      that,  no  matter  what  the  offset, steps the clock to the
>>>      indicatedA time.
>>>     
>>
>>
>> Is this really true? The first sample after 15 minutes is used, even if
>> it is a lone wolf? What if you have 5 servers and 4 of them give an
>> offset of 2 seconds and one has an offset of 10 seconds. If the 10
>> second guy happens to be the first one after 15 minutes of such
>> samples, he gets used? This seems wrong to me.
>>
>> Brian Utterback
>>
>> _______________________________________________
>> hackers mailing list
>> hackers at lists.ntp.org
>> https://lists.ntp.org/mailman/listinfo/hackers
>> _______________________________________________
>> hackers mailing list
>> hackers at lists.ntp.org
>> https://lists.ntp.org/mailman/listinfo/hackers
>>   
>
>



More information about the hackers mailing list