[ntp:questions] Re: HowTo calibrate system clock frequency using NTP

Richard B. Gilbert rgilbert88 at comcast.net
Thu Feb 2 14:25:37 UTC 2006


Daniel Kabs wrote:

> Hello Terje!
>
> Terje Mathisen wrote:
>
>> This is well within the expected precision for such an experiment, 
>> the final ntp.drift value (23.2 or 268.3) probably reflects the 
>> current drift rate, not the average.
>> These two values are different because the environmental temperature 
>> varies, often diurnally, so if you log the changes in ntp.drift then 
>> you'll probably notice that the average corresponds closely to the 
>> 23.7/23.8 numbers.
>
>
> Did I understand you correctly: You are insinuating that least-squares 
> fitting the time offset is getting an average value whereas the 
> frequency error (ntp.drift value) represents a "live" value.
>
> I expected it to be the other way round: I thought the frequency error 
> is a "slow" value that takes hours or days to converge as a result of 
> the control loop phasing in and as such can only slowly react to 
> environmental changes (e.g. change in temperature). This contrasts to 
> measuring the time offset over a short periode which gives a 
> "snapshot" of the current clock drift and as such represents current 
> environmental effects.
>
> What am I getting wrong here?
>
> Cheers
> Daniel

Ntpd begins correcting the frequency about five minutes after it is 
started (about twenty seconds with iburst).  Thereafter, the error is 
recomputed  at each poll interval and corrections made if necessary; by 
default, this would be not less often than every 1024 seconds.  The 
current value is written to the drift file once each hour, to provide a 
reasonable starting value if ntpd is restarted.

So, yes, it is a "live" value.  It would react slowly to large "steps" 
in the oscillator frequency but large steps are not the expected 
behavior because temperature changes do not normally occur in large steps.




More information about the questions mailing list