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

unruh unruh at wormhole.physics.ubc.ca
Sat Aug 27 21:10:44 UTC 2011

```On 2011-08-27, Chris Albertson <albertson.chris at gmail.com> wrote:
> On Sat, Aug 27, 2011 at 12:33 PM, unruh <unruh at wormhole.physics.ubc.ca>wrote:
>
>>
>> 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
>
>
> I said the time required to set the clock's speed to within one second per
> day if you can detect only one second error is one day.   This exactly
> matches what you propose above.
>

> Your fist step is "figure outexactly what the rate of the clock is"   How
> can you measure the clock's rate to a precision of one second per day unless
> you wait one day or can read the time to less than than one second?     So
> my 24 hour estimate of the time required to wait uses your method and
> assumes you do it perfectly, without error.

Except you can figure it out to 1us, not 1s.

>
> Yes NTP will "jump" the clock if the error is over 125 mS but in this
> context 125Ms error is  "way huge".  It is at least two orders of magnitude

You just told us that 1s is the best you can measure the error in one
second :-)

> over what NTP can do even in a very simple setup.  Jumping like that would
> only happen after along a period of being disconnected from a reference
> clock.

Or near startup if the clock rate was way out (100PPM) from what ntp expected.

With Linux, for a while the clock calibration routines were not very
good, and the calibration would fluctuate by of order 100PPM from one
boot to the next. Thus the rate saved from last time would be way out
from the current rate. If at the same time the clock had an offset error
(<125ms) the clock could easily drift out by that 125ms while ntp was
trying to bring it under control.

I think in the latest kernels, linux has fixed that calibration problem.

Ie 125 ms was not  a huge error in the normal run of things for ntp.

Now, independently measuring the offset and rate error is actually easy
even to 1PPM in a short time. Thus it should be possible to reset the
clock extremely quickly on startup, but not with ntp's algorthm.

```