[ntp:questions] The libntp resumee...

Unruh unruh-spam at physics.ubc.ca
Mon Oct 13 17:14:17 UTC 2008

mayer at ntp.isc.org (Danny Mayer) writes:


>>> Briefly, you use the defaults for MINPOLL and MAXPOLL.  You may use the
>>> "iburst" keyword in a server statement for fast startup.  You may use
>>> the "burst" keyword ONLY with the permission of the the server's owner.
>>> 99.99% of NTP installations will work very well using these rules".  If
>>> yours does not, ask here for help!
>> Now speaking about our system, not the middleware, with connections as 
>> follows: 
>> External NTPs <-> 2 entry hosts <-> 8 other hosts.
>> 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
>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.

The lower value on startup is to try to make ntp responsive at the
beginning, because it is so slow to correct errors. The longer value on
running is twofold-- to reduce the network demands on servers ( probably
the most important) and to increase the baseline for drift determination (
because of NTPs memoryless design) The former is important if you are using
public servers. The latter is important if you loose network connectivity
for days at a time. If you use your own server, and your network is stable,
a shorter maxpoll is better-- better control and faster response to
computer clock changes.


>> Currently we observe that both entry hosts can both become restricted due to 
>> large offsets on other hosts, so they become restricted and that will make 
>> the software refuse to go on. Ideally that would not happen.

>If the servers that it uses become divergent it will be unable to pick
>the "best" one and it will become unsynchronized.

>> I will try to formulate questions:
>> When the other hosts synchronize to the entry hosts of our system, don't the 
>> other hosts ntpd know when and how much these entry hosts changed their time 
>> due to input? 

No idea what this means. All a client gets is the offset of its clock with
respect to the server clock, and an estimate of the dispersion of the
server's clock. I do not know what "how much these entry hosts changed
their time due to input" means, but my guess is that the answer is "No, the
clients do not get any information about the internal workings of the

>> Would NTP would be more robust if we would configure routing on the entry 
>> hosts, so that they can all speak directly with the external NTPs on their 
>> own?

>Yes since the stratum will be lower so that the error budget will also
>be lower.

That depends on your routers. If you have routers with bad
latency/dispersion, it may be worse due to network delays/variability.

>> Is the use of ntpdate before starting ntpd recommended and/or does the iburst 
>> option replace it?

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

>> Best regards,
>> Kay Hayen

More information about the questions mailing list