[ntp:questions] Re: Drift handling....

David L. Mills mills at udel.edu
Mon Jan 2 20:49:22 UTC 2006

Roman, and others,

You should tae a closer look at the code in ntp_loopfilter.c. It throws 
nothing away. The main tool for adaptation to unstable clock oscillators 
is to vary the time constant according to measured stability. You will 
note the response to observed frequency transients is to reduce the poll 
  interval and increase it when the transient subsides.

In response to other posts here, the frequency estimate is updated at 
every clock update, not once per hour. Doing this once per day 
corresponds to an update interval of that magnitude, which is readily 
possible if you force minpoll to something large, as is done for the 
modem driver. The frequency file is written once per hour, but has no 
effect until the daemon is restarted.

I have learned over the years that a nonlinear response other than 
slowly varying the time constant, is not a good idea. There are limit 
checks which are necessary for reliable performance assertions, but 
nothing else. Finally, the frequency management has nothing to do with 
the leap second per se.

While all of the machines here took the leap in stride as expected, I am 
concerned about the varying reports posted here. So, I have been 
hammering away at various tests and have exposed what probably is a bug. 
If so, it has been around for a very long time and requires a most 
unlikely course of events. However, the effect would be as reported. 
Fixing it requires some subtle code realignment that make take a few days.

Roman Mäder wrote:

> it always surprised me how eagerly ntpd throws away the valuable drift
> estimate accumulated in the event of a sudden change in offset (even if
> there is an offset when it starts up). I can think of many reasons for a
> sudden change in offset, but nothing short of touching the crystal with a
> soldering iron should yank the frequency by values in excess of 500pps.
> Ther result are several time resets until things stabilize again, as we all
> know.
> Maybe a better strategy in the event of a significant sudden change in
> offset would be to behave in the same way it would with no drift file
> present: correct the offset, make a quick estimate of the frequency and go
> about your normal business.
> Roman Maeder

More information about the questions mailing list