[ntp:questions] NTP slow to start correction after a drift

David L. Mills mills at udel.edu
Wed May 14 21:11:24 UTC 2008


Bill,

You seem to have a tack up your tail about the clock filter algorithm. 
First, you didn't respond to my message about sampling at twice the 
Nyquist rate, even if a burst of seven samples is lost.

Second, look at the clock filter algorithm code and comments. Samples 
older than the Allan intercept (default 2000 s) are effectively 
discarded. Thus, only the latest sample is used and the next older used 
only to compute the peer jitter.

Third, if you recall my recent message about the poll algorithm, you 
know the jiggle counter is reduced if the (combined) clock offset 
exceeds twice the clock jitter. With the constants revealed in my prior 
message, and if the clock frequency is yanked 1 PPM by a Grue, all it 
takes is two samples and the poll interval/time constant drops by half.

Dave

Unruh wrote:

> Mike K Smith <mks-usenet at dsl.pipex.com> writes:
> 
> 
>>On 12 May, 15:16, "Richard B. Gilbert" <rgilber... at comcast.net> wrote:
>>
>>>Mike K Smith wrote:
> 
> 
>>>>Looks like I should be reducing maxpoll. I guess the design of NTP is
>>>>optimised for clocks with predictable drift rates, and a sudden
>>>>variation in drift rate takes longer to correct.
>>>
>>>You DO know that NTPD adjusts the poll interval to fit the current
>>>conditions??? =A0It will increase the poll interval to MAXPOLL only when
>>>the clock is stable and very close to being correct. =A0The default values=
> 
> 
>>>of MINPOLL and MAXPOLL are correct for all but the weirdest cases.
> 
> 
>>I know that ntpd adjusts the poll interval to fit the current
>>conditions, but I am describing a case where the current conditions
>>changed. The clock had been stable for around a week, and the polling
>>interval had increased to 1024 seconds, then something changed. It
>>looks like the clock started drifting by about 2ppm, the poll interval
>>didn't change for three hours causing a 15ms offset before beginning
>>to correct the drift.
> 
> 
> with a poll interval of 1024 the actual poll is about 8000 sec ( after the
> clock filter which throws away about 7 out of 8 data points). That is about
> 2 hours, so it is impossible for the system to even recognize that
> something has happened in less than about 2 hours. It can then try to start
> correcting and start to try to reduce the poll interval. Why does it throw
> away all that data? It is believed that the gain in using the minimum delay
> out of 8 is more than the loss in responsiveness, and in accuracy. (The
> procedure is to try to get rid of data which might have a large assymetric
> drift. ) This means that if the clock is 10ms out and the delay is .1ms, it
> may still be thrown out since that .1 ms is greater than the .095 ms
> achieved 7 poll intervals ago, despite the fact that the data shows
> incontrovertably that the clock is having far more problems than could
> ever be hidden in the delay.
> 
> 
>>I initiated this thread to help me understand why ntpd took so long to
>>respond. I had expected to see the poll interval decrease and the
>>offset swing back towards zero after the first couple of polls showed
>>the increased offset.
> 
> 
>>>Are you operating your machines in a controlled (temperature)
>>>environment? =A0If the temperature bounces around, so will your clock.
>>>NTPD will correct it but if the temperature drops five degrees in five
>>>minutes when the air conditioning kicks in, NTPD may have a little
>>>difficulty keeping up.
> 
> 
>>The systems are in air-conditioned equipment rooms, I wasn't expecting
>>to frequency changes due to temperature.




More information about the questions mailing list