Roman, and others,
You should tae a closer look at the code in ntp_loopfilter.c. It throws
nothing away. The main tool for adaptation to unstable clock oscillators
is to vary the time constant according to measured stability. You will
note the response to observed frequency transients is to reduce the poll
interval and increase it when the transient subsides.
In response to other posts here, the frequency estimate is updated at
every clock update, not once per hour. Doing this once per day
corresponds to an update interval of that magnitude, which is readily
possible if you force minpoll to something large, as is done for the
modem driver. The frequency file is written once per hour, but has no
effect until the daemon is restarted.
I have learned over the years that a nonlinear response other than
slowly varying the time constant, is not a good idea. There are limit
checks which are necessary for reliable performance assertions, but
nothing else. Finally, the frequency management has nothing to do with
the leap second per se.
While all of the machines here took the leap in stride as expected, I am
concerned about the varying reports posted here. So, I have been
hammering away at various tests and have exposed what probably is a bug.
If so, it has been around for a very long time and requires a most
unlikely course of events. However, the effect would be as reported.
Fixing it requires some subtle code realignment that make take a few days.
Roman Mäder wrote:
it always surprised me how eagerly ntpd throws away the valuable drift
estimate accumulated in the event of a sudden change in offset (even if
there is an offset when it starts up). I can think of many reasons for a
sudden change in offset, but nothing short of touching the crystal with a
soldering iron should yank the frequency by values in excess of 500pps.
Ther result are several time resets until things stabilize again, as we all
know.
Maybe a better strategy in the event of a significant sudden change in
offset would be to behave in the same way it would with no drift file
present: correct the offset, make a quick estimate of the frequency and go
about your normal business.
Roman Maeder
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
