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

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 '14 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 '14 at 15:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.