[ntp:questions] Polling time backoff
Richard B. Gilbert
rgilbert88 at comcast.net
Sun Nov 29 01:29:26 UTC 2009
shane-dated-2009 at csy.ca wrote:
> Just wondering if there is anything in particular which would keep ntpd
> polling its servers every 64s. I thought it was supposed to backoff to 1024s
> eventually but this doesn't seem to be the case here.
> continuum:~$ ntpq -p
> remote refid st t when poll reach delay offset jitter
> *GPS_NMEA(0) .GPS. 0 l 9 16 377 0.000 -0.006 0.001
> +dns1.uniserve.c 220.127.116.11 2 u 43 64 377 10.898 2.437 1.734
> -dns2.uniserve.c 18.104.22.168 2 u 50 64 377 9.005 -1.581 3.804
> +time.nrc.ca 22.214.171.124 2 u 24 64 377 72.240 1.565 5.935
> My ntp.conf is pretty boilerplate save the following bits.
> discard average 30
> discard minimum 3
> restrict default kod limited nomodify notrap nopeer
> restrict 127.0.0.1
> server 127.127.20.0 minpoll 4 prefer
> fudge 127.127.20.0 flag3 1 flag2 0
> The other servers are just server xxx iburst
> Isn't 64s too short a polling time? ntp version is 4.2.4p6 (Debian).
NTPD adjusts its polling rate to fit the conditions. If it is polling
at 64 second intervals forever, it is not happy with the quality of time
that it's getting from those upstream servers.
You might find it interesting to look at the output of ntpq in the early
morning hours, say between 0100-0600 local time. The net is much
quieter during those hours and ntpq shows that ntpd is happier with the
quality of time its getting. If it's still locked at 64 seconds further
investigation may prove fruitful.
More information about the questions