Tom,
Thank you for using plain ASCII, which with my dim eyes I can read much
more easily than curlicue.
The name of the frequency file in all versions known to me is ntp.drift.
The specific action of computing the initial frequency directly happens
only when that file is not present at startup. Setting its value to zero
defeats the purpose.
Interaction between the daemon frequency measurement and kernel
frequency measurement is a delicate art to avoid transients. The daemon
sets the daemon, PPS and kernel frequency to the value in ntp.drift at
startup. After each kernel update the daemon frequency is initialized
from the kernel. While the kernel is in control, the daemon frequency is
ignored. A similar thing happens with the PPS frequency. This allows
quasi-seamless switching beteen these sources when good times come and go.
What has happened in the past is somebody disabled the kernel with a
configuration command and forgot to tell the kernel to set its frequency
to zero. Therefore, the always safe action is to remove the ntp.drift
file and do ntptime -f 0.
Dave
Tom Smith wrote:
mike wrote:
The explanation is that the kernel also keeps a frequency drift value
that is persistent across boots. It is kept in /etc/adjtime. If this
file exists in your implementation, just removing it might be the
answer. It fixed my problem.
Interesting. Hadn't run into that one (yet). Maybe setting the contents
of the drift file to "0.000" instead of deleting the file would also
get around that hickup, if that (or something similar) is, in fact,
the problem.
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
