[ntp:questions] Polling time backoff

David Lord snews at lordynet.org
Sun Nov 29 04:51:11 UTC 2009


shane-dated-2009 at csy.ca wrote:
> Hi,
> 
> 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 140.142.16.34    2 u   43   64  377   10.898    2.437   1.734
> -dns2.uniserve.c 131.188.3.220    2 u   50   64  377    9.005   -1.581   3.804
> +time.nrc.ca     132.246.168.2    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).

I've seen same here on NetBSD with three different ntpd versions,
sometimes getting off 64s but then reverting back. This is only
since having a radioclock on one server with poll set to 64s.

Now I have minpoll 8 maxpoll 11 and now on two of my servers
all remote servers are currently settled at 2048s and on third
they are all settled at 1024s and have never reached 2048s.
Reason for maxpoll 11 is that the polls would increase to 68m
or 137m then ntpd is unable to react to frequency changes
needed to compensate for temperature variations here.

David




More information about the questions mailing list