You are not logged in.

#1 2012-09-21 13:19:15

Registered: 2012-09-02
Posts: 493

[solved] Ntpd: polling interval stuck at 64 s

I've switched from one-shot ntp updates at boot to ntpd yesterday. Everything works fine, but I've noticed the update interval ("poll" in the ntpq output) seems to be stuck at 64 s, no matter how long ntpd has been running:

# ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
-     2 u   46   64  377   57.993   -3.914   3.215
+   2 u   48   64  377   58.355   -4.997   2.041
+   2 u   49   64  377   58.183   -7.654   6.429
*    2 u   54   64  377   51.717   -5.382   1.119

The ntp.conf man page says the defaults are 64 s (min) and 1024 s (max), so why isn't "poll" increasing? I've even set a higher minpoll and maxpoll in the config file, see below, but the value is still stuck at 64 s for some reason.

Running 64 s update intervals for extended periods is putting undue strain on the time servers, so I'd really like ntpd to use a higher value.

# cat /etc/ntp.conf 
# With the default settings below, ntpd will only synchronize your clock.
# For details, see:
# - the ntp.conf man page
# -
# -

# Associate to public NTP pool servers; see

minpoll 8
maxpoll 12

# Only allow read-only access from localhost
restrict default noquery nopeer
restrict ::1

# Location of drift and log files
driftfile /var/lib/ntp/ntp.drift
logfile /var/log/ntp.log

# NOTE: If you run dhcpcd and have lines like 'restrict' and 'fudge' appearing
# here, be sure to add '-Y -N' to the dhcpcd_ethX variables in /etc/conf.d/net

P.S. I'm on a pure systemd setup, in case that's important...

P.P.S. I've noticed right now "poll" is at 256 s, i.e. 2**8. So at least the new minpoll value seems to work now.


Update, 2012-09-23:

Now the polling interval has finally hit 1024 s as it should! So my interpretation is that ntpd simply needs to run a few days before it actually uses the longer polling intervals.

Last edited by Morn (2012-09-23 16:55:10)


Board footer

Powered by FluxBB