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.
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
