Yo Hal! On Thu, 09 Jun 2016 01:09:25 -0700 Hal Murray <[email protected]> wrote:
> [email protected] said: > >> Are you confusing iburst with burst? > > Probably. The official descriptions are essentially identical, and > > the iburst seems a tad nicer to my eye. But we know that reading > > between the lines is not useful with NTP doc. :-( > > iburst happens at startup time. That includes restart for things > like plugging an Ethernet cable in. It lets ntpd get (re)started > (much) faster. > > burst happens every time it decides to poke the remote server, aka at > the poll interval. Hmm, that is not how I read the doc. Can you point me at some code? > If you are using your servers you can do anything you want. If you > are using a free resource (pool servers or public servers like NIST), > you should be polite. I don't know of any official pool rules. One > a minute is generally considered OK. I think I've seen something > like that on the NIST web site. I see that Redhat recommends iburst: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/sect-Date_and_Time_Configuration-Command_Line_Configuration-Network_Time_Protocol.html I see that the Pool guys object to burst and minpoll, but do not mention iburst: "So don't use more than four time servers in your configuration, and don't play tricks with burst or minpoll - all you will gain is extra load on the volunteer time servers." So good thing I have not ever advocated either on the pool. I just ran some tests. I found zero improvement to the pool servers with iburst/burst or even watching pings. They must get so much traffic that all the needed bits and pieces are live, not stuck in cache or needing ARP, etc. So I'd be OK with removing iburst from my peer section if you think that is best. But I would like a citation first. I do see burst/minpoll help locally. So I'm keeping it for my locals. Not a huge improvement, so I need to make longer tests. > burst has a bad reputation. If I read things correctly, the size of > the burst is adjusted to not go over the equivalent minpoll rate. > There is a ceiling of 8. So I don't see any problem. Neither do I > see any reason to use it unless you are working with dialup or very > low bandiwidth radio links. I do see they help locally for little used local peers. Like if the poll is longer than the ARP timeout. Of the ntpd gets swapped out on the remote. > Even without any bursting, reducing the polling interval below the > default 6 with minpoll/maxpoll is not friendly to pool/public servers. Nor have I suggested that for pool servers. For local servers I can detect a win. > Similarly, if you have lots of systems, you should setup your own > server (or a few of them) and have most of your systems get time from > your local servers. Which is what the config I first submitted does. > If I'm looking for documentation on something like iburst, I > generally try something like: > grep iburst docs/ -rl > And then poke around in the hits. I do not trust the NTP docs. Too much bit rot. And when reading the same line we can't agree on what it really mmeans. I want to see things in the source. But, back on task, my peer section is below. Are you OK with it other than the iburst thing? Are you OK with it with the iburst thing? If not, can you cite any reference against the iburst thing. # if you have no other local chimers to help NTP perform sanity checks # then you can use some public chimers from the NTP public pool: # http://www.pool.ntp.org/en/ # To use the pool servers uncomment the last four lines in this section. # The iburst option tells ntpd to query the pool serers with bursts instead # of single requests. This can yield better results to remote servers. # Notice I use the 'us' country code servers, otherwise I might get one # pool server from Ukraine and another from Singapore. If you are # not in the USA, then change the 'us' to your two letter country code. # server 0.us.pool.ntp.org iburst # server 1.us.pool.ntp.org iburst # server 2.us.pool.ntp.org iburst # server 3.us.pool.ntp.org iburst RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 [email protected] Tel:+1 541 382 8588
pgpCtXx8kg8sF.pgp
Description: OpenPGP digital signature
_______________________________________________ devel mailing list [email protected] http://lists.ntpsec.org/mailman/listinfo/devel
