[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 mailing list