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

Arnold arnold at hacktic.nl
Mon Jan 2 13:00:04 UTC 2006


On 01-01-06 15:44, David J Taylor wrote:
> It seems to me that a good proportion of my problems at the leap-second 
> were due to the drift file suddenly being set to a large value (just short 
> of 500).  NTP was able to recover from this on two PCs, but not on the 
> other two.  The drift file was altered to this new value within an hour of 
> midnight (UTC).
> 
> Is it possible to make it much less easy for NTP to alter the drift file 
> value - for example to require a different measured value for e.g. 24 
> hours before the drift is taken as having changed?  Of course, I only see 
> the value in the drift file, but I presume I am really talking about the 
> internal clock drift rate value.
> 
> Does altering that internal drift rate improve the stability over the 
> diurnal temperature cycle?  If so, could you do something like keeping a 
> drift history (say) once every 6 hours, so that a measure of the diurnal 
> instability was known by four samples, each averaged over several days? 
> And then, only if a whole day's values (four sets) were different, would 
> you assume that something really had changed?
> 
> I don't know if what I'm asking for is sensible or feasible, but I put it 
> up for comment.

I agree. Usually ntpd runs for a long time with almost the same drift
value, giving a lot of info about the stability of the hardware, and
confidence in the local clock. Two different routes:
- keep track of the 'confidence' in the drift value, and perhaps the
observed variance, or min/max values;
- use an other algorithm for the drift control loop, such that overshoot
does not occur, or in a more controlled way (handling steps is very
common in engineering with control loops).

With the first route, in case the local clock is 'suddenly' off by a
large amount (especially after selecting another server to sync with),
the local clock should not be adjusted by changing the drift value. Or
at least, the 'historic' drift should be remembered, so it can be
restored once the clocks are (almost) synchronised.

After all, frequency drift is about the duration of one second, and not
about offset (absolute time). With the perfect frequency drift
correction, your offset remains exactly the same. You can  temporary
adjust the drift value to reduce offset, but it has to be reset to its
old (stable) value afterwards. Otherwise, you might get overshoot and
'jumpy' behaviour, as observed by several of you, unless the algorithm
for the control loop is designed to avoid this.

Arnold &:-)




More information about the questions mailing list