[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