[ntp:questions] stepping and slewing

David L. Mills mills at udel.edu
Tue May 15 02:04:22 UTC 2007


You are absolutely right. To survive beyond reboot, it should read the 
frequency file. But, now the ntpd -gq code has to check if the kernel 
code is available and zap the kernel frequency accordingly.

This puppy is getting long of weeds; there are many combinations 
with/without kernel, with/without ntpd -gq, very large step thresholds, 
with/without PPS, maintaining kernel frequency following a daemon crash 
or long unreachable interval, using PPS in combination with other 
daemons or when the PPS and/or the prefer peer go dark.

I'll see what I can do, but the canonical behavior with this puppy is I 
mow a weed for someone and a new weed pops up in a surprising place.


Hal Murray wrote:

>>It is conceivable to run ntpd without -gq for a time in order to train
>>the frequency offset, then kill the daemon leaving the kernel variables
>>behind, and henceforth use only ntpd -gq.
>>To support reading the frequency file, the ntpd -gq would have to figure
>>out whether the kernel is available, read the frequency file and then do
>>a ntp_adjtime() to initialize the frequency. But, we just did that
>>during the training period.
> Only if you haven't rebooted since the training period.
> If you can't run ntpd all the time (for some strange reason),
> fixing the drift would be on top of my list.
> 3 machines that I have handy all have a drift over 100 ppm.

More information about the questions mailing list