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?
Afaik ntp.drift normally carries about an hour's worth of history.
It is rewritten every hour.
Terje
--
- <[EMAIL PROTECTED]>
"almost all programming can be viewed as an exercise in caching"
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
