How does an NTP client choose its poll interval between MINPOLL and MAXPOLL, and why does it lengthen the interval once its clock is stable?
answer
- powers of two seconds
- protocol limit versus reference code
- offset compared with jitter
- longer interval, longer averaging
- back off when unreachable
basics
~20 sAn NTP poll interval is a power of two seconds. RFC 5905 raises the exponent while measured offsets stay small relative to jitter and lowers it when they grow, so a stable clock polls rarely, averaging over longer spans and loading servers less.
solid answer
~50 sNTP sets the poll interval as an exponent: interval = 2^poll seconds. RFC 5905's parameter table bounds it with `MINPOLL` 4 (16 s) and `MAXPOLL` 17 (about 36 h); its header description suggests default limits of 6 and 10 (64 s to 1,024 s), and its reference code uses 6 and 17. The table is the protocol's limit; the others are defaults inside it. Within the bounds the interval follows the clock discipline's time constant: while each new offset stays under `PGATE` (4) times the clock jitter a hysteresis counter climbs, and at `LIMIT` (30) the exponent rises by one; larger offsets drive the counter down twice as fast and then the exponent down. A stable clock therefore polls less often, which lets the discipline average over longer spans and costs servers less, and a disturbance shortens the interval again. Separately, the interval doubles each poll once a server has stayed unreachable for a while, and burst options send eight packets 2 s apart.
go deeper
Recall that NTP's poll interval is a power of two seconds that grows when the clock is steady and shrinks when it is disturbed.
Explain the exponent, RFC 5905's 16-second-to-36-hour limits versus its suggested 64-to-1,024-second defaults, the offset-against-jitter hysteresis, and back-off while unreachable.
Diagnose from the poll value: a client stuck at its minimum sees large offsets or a noisy path, and burst options trade server load for faster start-up.
Choose poll bounds for a server population: faster start-up and tracking against aggregate query load on shared servers, and how clients behave when a server disappears.
## The poll interval is an exponent NTP never carries a poll interval in seconds. The `poll` field in the packet header and the client's poll variables hold a signed **exponent**, and the interval is `2^poll` seconds: | Exponent | Interval | |---|---| | 4 | 16 s | | 6 | 64 s | | 10 | 1,024 s (about 17 min) | | 17 | 131,072 s (about 36.4 h) | Raising the exponent by one doubles the interval; lowering it halves it. ## Three sets of numbers in one RFC RFC 5905 gives poll bounds in three places, and they differ: | Where in RFC 5905 | Minimum | Maximum | What it is | |---|---|---|---| | Figure 6, global parameters (§7.2) | 4 (16 s) | 17 (36 h) | the protocol's limits, `MINPOLL` and `MAXPOLL` | | `Poll` field description (§7.3) | 6 (64 s) | 10 (1,024 s) | "suggested default limits" | | Reference skeleton (Appendix A.1.1) | 6 (64 s) | 17 (36.4 h) | example code's constants | The global table defines the range the protocol works within; the other two are defaults chosen inside it. RFC 5905 also says some implementations make such parameters adjustable by configuration, so the bounds a given client uses are a local choice. "NTP polls every 64 seconds" is therefore wrong twice: 64 s is a suggested default floor, not the protocol's limit, and it is a floor, not a fixed rate. ## How the interval adapts RFC 5905 ties the poll exponent to the clock discipline's **time constant** (§11.3 and §13.2): when a server becomes reachable again, its poll exponent is reset to the time constant. The time constant moves by a hysteresis rule: 1. After each update, compare the magnitude of the new offset with the clock jitter. 2. If the offset is **greater than `PGATE` (4) times the jitter**, decrease the hysteresis counter by two; otherwise increase it by one. 3. When the counter reaches `LIMIT` (30), raise the exponent by one; when it reaches -30, lower it by one. 4. Clamp the result between `MINPOLL` and `MAXPOLL`. Because the counter falls twice as fast as it rises, the interval shortens quickly on trouble and lengthens only after a sustained calm stretch. RFC 5905 says the time constant normally "hovers near MAXPOLL, but quickly decreases if a temperature spike causes a frequency surge". ## Why lengthen when stable - **Better averaging.** Each update spans a longer interval, so network jitter is a smaller share of what the discipline measures, and its estimate of the clock's frequency improves. - **Less load.** A client that polls every 1,024 s sends one sixty-fourth of the packets of one polling every 16 s, which matters to servers with many clients. - **A limit to it.** If the interval grows so long that the oscillator's own wander dominates, averaging stops helping. RFC 5905's reference code caps its averaging at a constant it calls the Allan intercept (1,500 s), and the hysteresis rule pulls the interval back down when offsets grow. ## Other rules that move the interval - **Unreachable back-off.** While a server does not answer, its unreach counter rises each poll up to `UNREACH` (24); after that, each poll increases the exponent by one, doubling the interval up to `MAXPOLL`. On reachability returning, the exponent resets to the time constant. - **Never undersample.** The poll update routine uses the lesser of the client's own exponent and the `poll` value in the last packet received from that server, clamped to the bounds: "the clock discipline can be oversampled but not undersampled". - **Bursts.** With the `BURST` option, a client sends `BCOUNT` (8) packets 2 s apart at each poll, if the server is reachable and a valid source is available, to measure jitter better at long intervals. With `IBURST`, it sends such a burst on the first packet to a server that is not yet reachable, so the clock filter fills in seconds. RFC 5905 describes both as per-association flags, not mandatory behaviour. ## What an operator reads from it A client sitting at its minimum poll interval for hours is seeing offsets large relative to its jitter: a noisy path, an unstable oscillator or a disturbed source. One that has climbed towards its maximum has a calm clock. Changing the configured bounds trades tracking speed against query load; it does not change how sources are selected.
- Why is it wrong to say that NTP polls every 64 seconds?64 s is `2^6`, the default minimum RFC 5905 suggests and its reference code uses; the protocol's own limit, `MINPOLL`, is 4 (16 s). It is also a floor, not a rate: the exponent climbs towards `MAXPOLL` while offsets stay small relative to jitter, and keeps doubling once a server has stayed unreachable for a while. A settled client normally polls far less often than its minimum.
- What does a burst on first contact with a server trade away?RFC 5905's `IBURST` option sends eight packets 2 s apart when a server is not yet reachable, so the clock filter fills and the synchronisation distance drops below the 1 s threshold in seconds rather than over about four poll intervals. The cost is eight packets at once per server. It is an option the association enables, and a busy server may rate-limit clients that send too much, which is a separate subject.
saying these in an interview costs you the question
- NTP polls at a fixed 64-second interval defined by the protocol.
- RFC 5905 forbids NTP poll intervals shorter than 64 seconds.
- A client polls more often once its clock is stable, to keep it stable.
- Polling as fast as possible always gives better time.
- An unreachable server is polled more and more often until it answers.