[ntp:questions] how long does it take ntpd to sync up

unruh unruh at wormhole.physics.ubc.ca
Sun Aug 28 00:11:19 UTC 2011


On 2011-08-27, Harlan Stenn <stenn at ntp.org> wrote:
> Bill wrote:
>> On 2011-08-27, Chris Albertson <albertson.chris at gmail.com> wrote:
>>> Use some logic.   Assume you want to set a mechanical clock's speed by
>>> moving the "slow/fast" lever and you can see the time only to the nearest
>> 
>> Ah yes, but why a) would you want to only adjust it that way, an b)
>> why not do a fit and figure outexactly what the rate of the clock is
>> and how far out it is, and correct that, rather then simply "shove the
>> rate a bit higher if you see the clock time is behind time now, and a
>> bit slower if you see the clock is ahead." (which is what ntp does).
>
> Using phrases like "shove the rate a bit" seems pretty disingenuous to
> me, Bill.

?? Not sure what you mean? ntp works by altering the rate in order to
eliminate the offsets. Is it the infomality of "shove" you object to?

>
>>> second by eye.  If you want the clock to lose/gain one second per
>>> day then it will take you one day (at best) to adjust the time as it
>>> would take that long to detect an error.
>
> It may take a day for the error to be out by a full second, but that in
> no way means it takes 24 hours' time to discover that the local clock is
> running at a rate that is off by 1 sec/day.  If the time is usefully
> measurable to, say, 1 msec (just to pick an easy target), then we'll
> "notice" an error of this rate in about a minute and a half.  If we can
> get usefully measurable time to .1 msec, then we can notice that error
> in less than 8.7 second's time.

His hypothesis is that you can only measure the time offset to within a
second. No idea why.

>
>>> If you want to adjust the rate such that it only gains one second per
>>> month it would take a month before you'd know if you got it right.
>
> No... see above.
>
>>> You have to remember that NTP works be adjusting the rate, faster or
>>> slower and tried hard to never "jump" the time.  The only why for
>>> anyone to know if the rate is right is to wait, greater accuracy
>>> requires longer a wait.
>> 
>> But ntpd has no compunction about jumping the time if it is out by 125
>> ms. It does not try very hard not to jump the time at all. 
>
> 128 ms.
>
> ntp is designed to work well in a pretty wide variety of circumstances.
>
> The model says that we adjust the time at a rate that does not exceed
> 500ppm, and that the computer's clock will keep time at a rate that is
> not more than 500ppm away from "correct" time.

except when you jump the time, at which point it is a rate that is
infinitely different from the true rate. 


>
> It is usually much better than that.

Agreed.

Usually you do not run into either the 500PPM limit or the 128 ms jumps.
However, at a restart you can, especially if, as with the older Linux
kernels, the rate changes by up to 100PPM between separate boots. 


>
> Once ntpd has gotten the local clock sync'd, there should be no cases
> where the clock diverges by 128ms - if it does there is another problem,
> and that problem should be found and fixed.  Given the time it takes to
> "amortize" a correction of 128ms, do you feel it is better to not "step"
> that correction?  If you don't like the 128ms value you can change it.

A "jump" is an infinite rate. Thus ntp says that it will only change
rates by up to 500PPM except when it is infinity. Is that better than
say removing that 500PPm limit and allowing the system to correct for up
to say 100000 PPM( the limit of the adjtimex function under Linux).

>
> This is not to say that different algorithms would not do "better" for
> some folks, and we're taking steps to make it easier to deploy and test
> different algorithms.
>
>>> NTP works kind of like this.  Small errors take a long time to detect
>>> and smaller errors take even longer to detect.  So up to a point
>>> NTP's error
>> 
>> no, an error in offset of 1 usec can be detected immediately if you
>> have a good reference (and almost never if you do not) . And an error
>> in rate of 1 usec/s can be detected easily within a minute.
>
> Yup.
>
>>> So the conservative answer is "24 hours" but for most practical
>>> purposes you are "good enough for file system time stamps and the
>>> like" after 1 or 2 hours.
>> 
>> Depends on your accuracy requirements. 
>
> and as I mentioned elsewhere, it is "normal" for this stability to be
> had within 11 seconds' time of ntpd starting.  And if no good drift file
> is available, I believe that number increases to around 15 minutes' time
> (more or less).
>
> If you have sufficiently-motivating need for even better time stability,
> then relying exclusivelyl on internet time servers doesn't seem
> ... appropriate.

Many now use say gps which can give better time stability than that,
using ntpd.

>
> H




More information about the questions mailing list