[ntp:questions] The libntp resumee...

Unruh unruh-spam at physics.ubc.ca
Fri Sep 5 21:41:59 UTC 2008


kayhayen at gmx.de (Kay Hayen) writes:

>Hello Richard,

>you wrote:

>> The "rules" about how often to query a daemon are not all that
>> complicated.  The fact that there ARE rules is due to some history;
>> google for "Netgear Wisconsin" for the sordid details.  For a "second
>> opinion" google for "DLink PHK".

>Fascinating reads indeed, thanks for the pointers. 

>What worried me more was how often we can query the local ntpd before it will 
>have an adverse effect. Meantime I somehow I sought to convince me I should 
>be able to convince myself that ntpq requests are served at a different 
>priority (other socket) than ntpd requests are. I didn't find 2 sockets 
>though.

Depends on the system but thousands of times per second is not out of the
ballpark. I assume you are not planning anything that severe.
(Some servers bombarded by those idiotic people I believed managed those
kinds of rates.)


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

On which? That should NOT be on the external NTPs unless you own them. That
will not necessarily improve results-- depends on whether you want short
term accuracy or long term (eg what happens if the connection with the
outside world goes down for 3 days. Do you want to make sure your systems
will keep good time during those three days? Are you willing to buy 25usec
rather thahn 50usec short term accuracy for 10 sec drift over that 3 days?



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


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

Yes, and no. On one level no-- they trust their sources. However part of
the information they get is the dispersion. That gives some info about how
well those servers are tracking the outside world.


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

Multiple paths are always more robust than one path. 

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

Not recommended. 




More information about the questions mailing list