[ntp:questions] Re: time reset, syncronisation lost and Large PPM values
David L. Mills
mills at udel.edu
Mon Oct 24 04:37:15 UTC 2005
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.
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.
More information about the questions