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 ============================================================================== -220.127.116.11 18.104.22.168 2 u 46 64 377 57.993 -3.914 3.215 +22.214.171.124 126.96.36.199 2 u 48 64 377 58.355 -4.997 2.041 +188.8.131.52 184.108.40.206 2 u 49 64 377 58.183 -7.654 6.429 *220.127.116.11 18.104.22.168 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 # - http://support.ntp.org/bin/view/Support/GettingStarted # - https://wiki.archlinux.org/index.php/Network_Time_Protocol_daemon # Associate to public NTP pool servers; see http://www.pool.ntp.org/ server 0.de.pool.ntp.org server 1.de.pool.ntp.org server 2.de.pool.ntp.org server 3.de.pool.ntp.org minpoll 8 maxpoll 12 # Only allow read-only access from localhost restrict default noquery nopeer restrict 127.0.0.1 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.
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)