Hal, 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. Dave 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. > _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
