[ntp:questions] Wrong time after changing hardware
David L. Mills
mills at udel.edu
Fri Jul 27 19:46:24 UTC 2007
See line 234 et seq in ntp_util. To my knowledge the scheme has changed
twice since the original 1992 code. The first change was not by me and
only recently discovered. It was broken. The latest change by me, along
with the tuning parameters, should be stable now in ntp-dev.
The scheme writes the file only if the clock stability aka wander
computed by the clock discipline algorithm is above a dynamic decreasing
variable called the wander threshold. The wander computation is the
exponentially weighted root-mean-square (RMS) of past frequency changes,
so if the temperature surges, for example, the frequency file will be
written more often, but not less than one hour and only once per server
update. The wander threshold is reset when the file is actually written.
The reason for the decreasing threshold is to insure that the file is
written at "reasonable" intervals, like once per day or once per poll
interval, whichever is less. This scheme was borrowed from the original
ARPAnet routing update policy, where the frequency of routing updates
depended on the measured churn, but insured that an update was sent at
minimum rate, even it the churn was small.
The reset wander threshold can be adjusted using the second argument of
the driftfile command. It defaults to 1e7 (0.1 PPM) The wander
computation itself is revealed in the sixth column of the loopstats file.
Harlan Stenn wrote:
>>>>In article <f87nle$eik$1 at hedeland.org>, per at hedeland.org (Per Hedeland) writes:
> H> I *think* that independent of this defalt value or one provided by -f, if
> H> the file does not exist ntpd will not create it.
> Per> Hm, maybe someone that actually *knows* could comment - I'm not able to
> Per> check it out myself ATM. ...
> I'm probably not going to dig and give a definitive answer because Dave is
> in the middle of changing how the driftfile is written and the dust hasn't
> The current mechanism is something like:
> - if the previous drift compensation value differs from the current
> value by more than clock_phi, do not write.
> - if we are in state 4 and the current clock_stability is greater than
> a slowly decreasing wander threshold, reset the threshold and write
> the driftfile.
> It is also very possible that the behavior/rules regarding the writing of
> the driftfile has changed once or twice over the years.
More information about the questions