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

Harlan Stenn stenn at ntp.org
Sun Aug 28 01:29:52 UTC 2011

```Bill wrote:
> 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?

ntp *does* a fit/figure of the expected needed adjustment - your
sentence implies that it does not (at least that's how it reads to me).

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

Yup.

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

Right, and when ntpd does that it *knows* it is doing that.

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

Yes, that's a different problem...

>> 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).

Do you want to re-do the algorithmic analysis of everything NTP does to
make sure that it behaves OK in all circumstances if you bump the limit
to 10000ppm?  And what about kernels that do not currently allow changes
to be applied at that rate?

There are also the issues of if we should prepare for the case where the
rate to advance the clock is different from the rate to retard the
clock.

I've long wondered about this - there are known needs for many folks to
have a monotonic clock.  That means that forward jumps are OK.

It means that it should be possible to allow the clock to step forward
but slew backwards.  We don't have a mode for this right now.

But I think the better solution is one I've been thinking about for a
while, where we have an "augmented" timestamp that includes a few more
bits of information.  I"ll be talking more about this Later.

>>>> 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 exclusively on internet time servers doesn't
>> seem ... appropriate.
>
> Many now use say gps which can give better time stability than that,
> using ntpd.

Yup, but this discussion seems to be more about sites that don't have
GPS units.

H

```

More information about the questions mailing list