Shippable ntp.conf files for the HOWTO

Gary E. Miller gem at
Thu Jun 9 18:14:44 UTC 2016

Yo Hal!

On Thu, 09 Jun 2016 01:09:25 -0700
Hal Murray <hmurray at> wrote:

> gem at 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:

I see that the Pool guys object to burst and minpoll, but do not mention

    "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:

    # 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 iburst
    #  server iburst
    #  server iburst
    #  server iburst

Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at  Tel:+1 541 382 8588

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the devel mailing list