[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