[ntp:questions] Polling time backoff
mills at udel.edu
Mon Nov 30 16:24:35 UTC 2009
The behavior you report is correct. Most of the refclocks have maxpoll
clamped at 64 s. As long as one of them is the system peer, the
discipline loop time constant is clamped to that value. However, if all
refclocks go away, some other server might take over leaving the time
constant at the minimum at least for awhile. If the server was running
at a large poll interval, the loop delay would become very large and
result in an unstable condition. So, if you configure addiitional
servers as refclock backup, they will have to run at 64-s interval as
long as a refclock is reachable..
shane-dated-2009 at csy.ca wrote:
>>Dave Hart <davehart at gmail.com> writes:
>>>On Nov 28, 11:52=A0pm, shane-dated-2... at csy.ca wrote:
>>>>Just wondering if there is anything in particular which would keep ntpd
>>>>polling its servers every 64s
>>>>server 127.127.20.0 minpoll 4 prefer
>>>>fudge 127.127.20.0 flag3 1 flag2 0
>>>The refclock is holding the poll interval down. You have to use
>>>minpoll on the remote server lines to force them to a longer poll
>>>interval in the presence of a reflock with a smaller poll interval.
>>Is that really right? I thought that all of the clocks had their poll intervals
>>determined independently. YOu seem to be saying they do not, that the poll
>>intervals are "universal" the smallest poll interval for any server is used.
>>On my system that is certainly not true
>Hmm, I think Richard Gilbert's post was pretty well spot on, watching the
>poll last night, it did go as high as 512 at around 2 AM for some of the
>servers. I just unconfig'd the refclock to see if that's making a difference
>but so far, polling is still at 64s. A bit odd, my connection to the net
>isn't terrible, res. cable connection but delays are decent. It's asymmetric
>though which I understand can give ntpd some grief.
>I have my net speed throttled slightly below upstream max so I can do packet
>prioritization and have ntp packets pretty high up in the queues so it's not
>like they're being held up in the modem buffers either.
>questions mailing list
>questions at lists.ntp.org
More information about the questions