unruh wrote:
On 2013-04-28, Harlan Stenn <[email protected]> wrote:
For years I've wanted the drift file to include the frequency/tick
values in-use when the drift file was written. Doing this would allow
ntpd to know if the tick value or frequency that it reads from the drift
file matches the current operating values or not, and take appropriate
steps.
I am not sure, but I thought that in the case of the Linux inability to
consistantly calibrate the system clock, the frequency and tick values
were always 0. It was the calibration behind the scenes which set what 0
meant that was at fault.
That was my reaction as well, but then I realized that Harlan had to
mean the actual tick value, i.e. nominal Hz rate and/or clock increment
per tick.
With a reboot that results in a different base tick, this would lead to
an obvious change in the validity of the ntp.drift numbers.
Obviouly if the user changes those values (to bring the drift closer to
zero for example so ntpd is not working so hard trying to compensate for
a "way off" calibration) then ntpd should know about it.
This is effectively what Linux did for a number of years.
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
