[ntp:questions] Wrong time after changing hardware

David L. Mills mills at udel.edu
Fri Jul 27 19:46:24 UTC 2007


harlan,

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.

Dave

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
> settled.
> 
> 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.
> 
> H




More information about the questions mailing list