[ntp:questions] ntpd -q and driftfile

unruh unruh at wormhole.physics.ubc.ca
Tue Mar 22 18:58:22 UTC 2011


On 2011-03-22, David J Taylor <david-taylor at blueyonder.co.uk.invalid> wrote:
>
> "unruh" <unruh at wormhole.physics.ubc.ca> wrote in message 
> news:slrniohmmc.6v5.unruh at wormhole.physics.ubc.ca...
> []
>> ntpd -q is a replacemtn for ntpdate, which was typically run from cron,
>> and he is doing, and it is an "acceptable" procedure if for example you
>> do not want a daemon running which could have (unknown to you) security
>> issues. It is also a bit unclear how to switch off the server role of
>> ntpd and he may not want others querying his machine. On the other had
>> it comes at a cost of far worse clock discipline and the probability of
>> the computer jumping backwards in time.
>
> For a one-off invocation, "acceptable", but to use it for repeated 
> periodic invocations would require further justification, in my view.
>
>> One hour? More like 10 hr. ntpd is really bad at recovering from
>> changes, and switchon is a big change.
>> After 1 hr the drift is liable to be way off, as ntpd alters the drift
>> to bring the clock back into line.
>
> In my experience, NTP writes the drift file every hour, not every ten 
> hours.  Even after one hour, the drift value is likely to be of more use 
> than no drift value at all.

I have seen the drift out by 400PPM at around the hour mark. ntpd
massively overswings to correct any intial error in the clock ( say a
few ms) , and then gradually
settles back  toward the correct drift rate. Thus the drift printed into
the file during that transient really has little relation to the true
drift rate, and is not very helpful.

Now, if the clock is close to the correct time, and the system had a
reasonable drift rate in the file before hand, then the drift rate
published after an hour may well be pretty close to the right rate. But
if the clock was say out by 50ms, then it could get pretty hairy. 
This problem is caused by ntp having no memory, except for the drift
rate and the current time. It thus cannot use the past history of
offsets to make a better estimate of what the true drift rate is. The
drift rate it has now is a sum of the true drift rate and the drift
rate being used to correct the clock offset. While with history, it
would be trivial to calculate the true drift rate and disentangle the
two ntpd does not do that. (chrony does). 


>
> Cheers,
> David 
>




More information about the questions mailing list