[ntp:questions] The libntp resumee...

David Woolley david at ex.djwhome.demon.co.uk.invalid
Mon Oct 13 09:08:18 UTC 2008

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 

> 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