Why doesn't NTP increase polling interval when using a GPS/PPS receiver and internet servers?

Question

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 127.127.22.0 minpoll 4 maxpoll 4
fudge 127.127.22.0 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

Answer 1

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.

Answer 2

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:

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.