[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