What is the minimum interval between retries to an unresponsive NTP server?

Question

ntpd is the reference implementation of NTP. The current version is 4.1.2.

The manual page seems to say that when iburst is used, the interval between retries to an unresponsive NTP server is 16 seconds.

http://doc.ntp.org/4.1.2/confopt.htm

iburst

When the server is unreachable and at each poll interval, send a burst of eight packets instead of the usual one. As long as the server is unreachable, the spacing between packets is about 16s to allow a modem call to complete. Once the server is reachable, the spacing between packets is about 2s. This is designed to speed the initial synchronization acquisition with the server command and s addresses and when ntpd is started with the -q option.

But the official NTP "handbook" says the retry interval will be raised to 64 seconds (assuming default settings):

https://www.eecis.udel.edu/~mills/ntp/html/poll.html

For the iburst option the number of packets in the burst is six, which is the number normally needed to synchronize the clock; for the burst option, the number of packets in the burst is determined by the difference between the current poll exponent and the minimum poll exponent as a power of 2. For instance, with the default minimum poll exponent of 6 (64 s), only one packet is sent for every poll, while the full number of eight packets is sent at poll exponents of 9 (512 s) or more. This insures that the average headway will never exceed the minimum headway.

The burst options can result in increased load on the network if not carefully designed. Both options are affected by the provisions described on the Rate Management and the Kiss-o'-Death Packet page. In addition, when iburst or burst are enabled, the first packet of the burst is sent, but the remaining packets sent only when the reply to the first packet is received. If no reply has been received after a timeout set by the minpoll option, the first packet is sent again. This means that, even if a server is unreachable, the network load is no more than at the minimum poll interval.

Should I understand the interval between retries will actually be 64 seconds when using iburst, unless the minpoll option is also adjusted?

Answer 1

The iburst setting alters the server setting so that until the server is reachable, at each poll interval eight packets are sent instead of one. (The interval between each of the eight packets is either 16 seconds or 2 seconds, depending on whether or not any response is received.)

To try and answer your question specifically, the interval between polling retries will be at least 64 seconds whether or not iburst is used.

• When iburst is not used, one packet will be sent per server polling retry.
• When iburst is used, up to eight packets will be sent at either 16 second or 2 second intervals for each polling retry.
• Once the server is considered reachable (and therefore a candidate for synchronisation), the iburst flag has no futher effect.
• To use the iburst semantics once a server is a candidate for synchronisation, add the burst flag.
• It is permitted (but not necessarily recommended) to use iburst and burst for the same server.

---

After some experimentation, here is what actually happens for me:

• When iburst is specified and the server does not reply, one packet is sent every polling interval.
• When iburst is specified and the server does reply, an initial sequence of six packets are sent, one every two seconds. This is not repeated at subsequent polling intervals, and iburst has no further effect. This sequence of six packets is sufficient to mark the server as a potential candidate for synchronisation (* in the left-hand column of ntpq -np).
• Once iburst has no further effect, a single packet is sent every polling interval.
• Each successful polling interval increments the reachability by 1 (actually consider it a bitwise shift register with 1 being pushed in as the LSB); once it reaches 777 - in octal - corresponding to nine consecutive successful poll intervals, the server becomes a possible synchronisation source.

Very little of this matches the current documentation!