[ntp:questions] The libntp resumee...

David L. Mills mills at udel.edu
Tue Oct 14 03:53:03 UTC 2008


David,

The ntpd parameter constellation is indeed tuned for a necessarily wide 
range of scenarios and may not be optimal for any particular case. From 
an engineering point of view the solution for the minpoll/maxpoll issue 
is obvious. Determine the Allan intercept as described in several 
places, my papers and my book. The poll interval is carefully set at 
1/32 the time constant, which should be at the intercept. So set minpoll 
and maxpoll to the log2 of that value. Yes, the loop is purposely 
oversampled with respect to the time constant, but not with respect to 
the Allan intercept.

The Allan deviation characteristic displayed in the briefings on the NTP 
project page should give a hint how the intercept varies with different 
operating systems and network links. Indeed, if you have a fast LAN, 
PCnet NIC and 3-GHz machine, the optimum poll interval is probably more 
like 4 (16 s), but probably not 3 (8 s), as that invites increased 
vulnerability to frequency surges.

The poll adjust algorithm does not do what you expect. See line 644 et 
seq in ntp_loopfilter.c and the commentary there. This algorithm is the 
result of literally 25 years of experiment and refinement. It is not 
necessarily designed for rapid initial convergence; it is designed to be 
sensitive to frequency surges once convergence has stabilized. The 
frequency file avoids initial convergence if restarted after that.

Dave

David Woolley wrote:
> Danny Mayer wrote:
> 
>> Kay Hayen wrote:
> 
> 
>>> And iburst and minpoll=maxpoll=5 to improve the results.
>>
>>
>> This indicates that you don't understand NTP. You should never ever
>> change the minpoll and maxpoll values unless you understand the NTP
>> algorithms in detail and understand the consequences of changing them.
>> The default values were very carefully chosen to provide a balance
>> between various conflicting requirements to provide the most stable
> 
> 
> Those conflicting requirements make assumptions about the environment in 
> which NTP is operating.  Those assumptions probably aren't valid when 
> the servers are on the same high speed, low traffic, network.  Having 
> said that, one shouldn't just set minpoll and maxpoll low, but should 
> actually measure the results and find optimum values for the actual 
> conditions.
> 
>> clock discipline over a wide range of environments. You are
>> undersampling at the start of NTP and then oversampling as it starts to
>> stabilize the discipline loop.
> 
> 
> ntpd always oversamples.  Changing the limits limits the range of filter 
> time constants  used.  Setting it low, improves convergence on startup, 
> and re-convergence after a temperature change, which is why there is so 
> much use of it - ntpd is failing to meet a market demand, and setting 
> both these low has become the urban folklore solution.  It also tends to 
> minimise the value of "offset" at other times, but that is not 
> necessarily good, as offset is not the same thing as error, and, 
> ideally, would be uncorrelated with it.
> 
> (ntpd starts to back off the time constant long before the startup 
> transient is complete, so keeping it artificially low helps there.  For 
> temperature changes, it takes time for the time constant to ramp down, 
> which is avoided by keeping it low.)
> 
> The reasons for not doing it are that it makes ntpd try to follow short 
> term variations in offset, which are likely to be due to network 
> conditions, rather than true time errors, and it makes the frequency 
> less stable, which means that short durations are measured less 
> accurately and time will diverge more quickly if connections to the 
> servers is lost.  It also imposes an unnecessary load on the servers.
> 
>> ntpdate is deprecated and is not normally needed. Make sure you start
>> ntpd with the -g option to step the clock initially to close to the
>> correct tick.
> 
> 
> -g doesn't step the clock, it simply allows the clock to be stepped by 
> more than 1000s, the first time.  Clock stepping is still subject to the 
> 128ms minimum offset.  Both numbers are configurable, although changing 
> them may disable some functions.
> 




More information about the questions mailing list