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

Brian Utterback brian.utterback at oracle.com
Sun Aug 28 12:10:50 UTC 2011

On 08/28/11 06:53, David Woolley wrote:
> Harlan Stenn wrote:
>> 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).
> No it doesn't.  It is basically a feedback controller.
> If you take a modern central heating controller, which varies the output
> by varying how much of a ten minute cycle the pump is running, you have
> something similar to version 3 ntpd, except that it used 4 seconds.
> The central heating controller will use the measured difference from the
> target temperature to adjust the on to off proportion, and also include
> some of the integral of that, to, eventually, remove any remaining offset.
> A fitting process would be more like the controller measuring the rate
> of temperature change when the heat was off, and when it was on, and
> then calculating exactly how much on to off time to apply in one go. (In
> practice, it isn't as simple as that for the central heating system, as
> there is a lag involved for the heat to get from the boiler flame to the
> the thermostat.

I think that there might be something to the process that Bill supports,
at least in some situations. As you know, I have had problems with NTP
and larger initial frequencies. (I know I owe you testing on the latest
NTP. Sorry, I have been busy. I'll get to it soon.) But if you think
about it, we already do something like this for offset.

Of course, NTP uses a PLL in the general case. (It used to use a FLL
when it settled in, but I seem to remember Dr. Mills saying that was
removed.) but with iburst, we futz with the algorithm to get the offset
right quickly. Couldn't we do something similar for frequency?
Particularly in the case where there is no drift file, the initial
frequency could be very far off. Save the first 16 (say) poll samples,
correct for the offset adjustment, do a best fit analysis and some
sanity checking and use the result for an initial frequency. You could
keep this up, doing best fit analysis until it got to within a certain
error interval and then switch to the normal regime.

If you only did the first analysis, you could trivially prove that it
does not break the PLL because you are left with an initial condition
that potentially could have occurred anyway. But in most cases, you are
going to zero in on the right frequency pretty quickly.


Always code as if the guy who ends up maintaining your code will be a
violent psychopath who knows where you live. - Martin Golding
Brian Utterback - Solaris RPE, Oracle Corporation.
Ph:603-262-3916, Em:brian.utterback at oracle.com

More information about the questions mailing list