[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?
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