I have a Debian system that is used as an NTP server. It queries several servers on the internet and also has a GPS receiver with PPS output for precision timekeeping.

If I don't use the GPS receiver, NTP gradually increases the polling interval from the initial interval of 64 seconds up to the default maximum of 1024 seconds, typically within an hour or two. This is normal behavior and generally considered polite since it minimizes the amount of queries made to the internet servers while still keeping the local clock in sync.

However, when I connect the GPS receiver and add the appropriate lines to the ntp.conf file to allow NTP to use it as a source, the behavior changes: even though I have not changed any of the individual server entries for the internet servers, their polling interval does not increase and remains fixed at 64 seconds even after days go by.

The PPS signal keeps the local clock well-disciplined (ntpq -p reports an offset of 0.000 ms with a jitter of 0.002 ms, with all the internet servers within about 2 ms), while the tally codes in ntpq -p confirm PPS discipline and show, as expected, that most of the internet servers are selected as "truechimers" while there are occasionally a few outliers.

In short: everything appears to be working normally as expected, with the exception that the polling intervals for the internet servers do not increase. Why not?

I can manually force the polling interval longer by putting, for example, minpoll 10 in the server lines for the internet servers, but I'd much rather have NTP auto-manage the polling interval of internet servers when PPS is enabled, just like it does when PPS is not used.

I currently have NTP set to check the PPS driver with minpoll and maxpoll of 4 (16 seconds). However, I have tested the configuration without the forcing minpoll or maxpoll on any server line, including that for the PPS driver.

Here is the relevant portion of my ntp.conf file:

# Drift file
driftfile /var/lib/ntp/ntp.drift

# PPS Driver (check every 16 seconds)
server minpoll 4 maxpoll 4
fudge refid PPS

# Internet servers. Use iburst to get quick sync on startup.
# Server is located in Switzerland, so choose Swiss or German
# primary time servers and members of the Swiss NTP pool.
# At least one "prefer" server is needed for PPS to work properly.
# See <http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver22.html>
# "This driver is enabled only under one of two conditions..."
server ntp.metas.ch iburst prefer
server ptbtime1.ptb.de iburst prefer
server ptbtime2.ptb.de iburst prefer
server ptbtime3.ptb.de iburst prefer
server 0.ch.pool.ntp.org iburst
server 1.ch.pool.ntp.org iburst
server 2.ch.pool.ntp.org iburst
server 3.ch.pool.ntp.org iburst

2 Answers 2


The short answer is "because Prof. Mills et. al. said so." There is a bug^1 questioning this behavior. In the discussion two of the ntp developers have said that the refclock's "64s polling interval keeps network source's poll interval from increasing" and that this behavior is intentional.^2 They also mentioned that if the minpoll clamping is really a big problem for you that you can (as you have discovered) manually set the minpoll for the remote servers to whatever value you prefer. However they cautioned that this behavior was not advised.

The slightly more technical answer is that in the presence of a refclock the time constant^4 used for clock discipline is also used for the poll interval.[^5] It is worth noting that they said they would revisit the issue if could explain why this behavior is such a problem.

Side note: With that many sources you should increase the minclock/minsane settings. At a minimum:

tos minsane 4 minclock 4

Is there a reason why you are only using the PPS and not using the NMEA sentences? I have a NMEA/PPS equipped ntp server at home and I have a couple external sources marked as noselect with minpoll 10 so that I can notice if something is wrong with my server. Most modern GPSs will do just fine with the antenna on the window sill.

  • Excellent, thank you. The link to the bug report is particularly appreciated, though I do wish that the developers explained a bit more clearly why this behavior is intentional -- it seems like the only role of internet servers in a PPS-disciplined system is to disambiguate the seconds and provide sanity checking but otherwise they don't normally contribute to timekeeping (assuming I understand the discipline algorithm correctly). Backing off to longer intervals seems more polite to internet timeservers by reducing unneeded traffic.
    – heypete
    Feb 21, 2014 at 15:13
  • In regards to the minclock/minsane settings, I don't typically use that many sources: it had added them strictly for testing purposes to see if the polling interval had any dependence on stratum or upstream time source. Additionally, I typically use the 127.127.20.x generic NMEA/PPS driver but switched to the PPS-only driver specifically for testing this issue: by having internet-only (no PPS) and internet-with-PPS configurations I could test the effect of a single change. Adding an extra variable in the form of NMEA would complicate testing. Also, your link #5 doesn't work.
    – heypete
    Feb 21, 2014 at 15:22
  • A warning about tos minsane 4 minclock 4: If you have only three "sane" time sources, you clock will not sync. It may not be very obvious from the status. However if you are sure you always have that many valid time sources, you can use that. monsanesays how many valid clocks are required, while minclock says how many clocks to consider from the pools. I'd use "minclock >= minsane +2"...
    – U. Windl
    Nov 24, 2023 at 8:04

The polling interval has three "components":

  1. Short polling intervals will cause the offset to be adjusted quickly, but due to random jitter, the frequency may not be very stable

  2. Long polling intervals cancel the random jitter, leading to higher frequency stability, while the offset increases towards the end of the polling interval

  3. Short polling intervals increase the network load on public servers (those are handling thousands of requests per second)

For illustration, there's a graphical comparison of polling interval, frequency adjustment and offset:

NTP performance values compared (poll, freq, offset)

The server shown limits maxpoll to 9 (as NTP is rather slow decreasing the polling interval when the frequency changes due to temperature variations).

So the third point does not apply to local reference clocks, leaving only the first two. Polling very shortly may result output jitter being derived from input jitter, while polling rarely may cause an offset much higher than the reference clock has. So 64 seconds had been determined (many years ago) to be the optimal compromise for local clocks (see also "Accuracy" and "Allan Deviation" in "Time and Frequency from A to Z" (NIST)).

Still you can force a shorter polling interval adding something like minpoll 4 maxpoll 5 to your server line.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .