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

David L. Mills mills at udel.edu
Sun Aug 28 23:31:54 UTC 2011


Brian,

See the release notes for the latest distribution in the online 
documentation.

There has been a bit of facebook engineering in this discussion. For the 
real story, see the How NTP Works pages in the latest online documentation.


Dave

Brian Utterback wrote:

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




More information about the questions mailing list