[ntp:questions] Re: Question on abusive clients.
David L. Mills
mills at udel.edu
Tue Dec 27 14:37:53 UTC 2005
Carefully read my pouty lips. Time constant, time constant. When the
time constant is forced small, switching to a long poll interval is
unstable. Really, really. That's the design consideration. You might be
able to get away with doing that in fact, but that's not the design intent.
Richard B. Gilbert wrote:
> David L. Mills wrote:
>> The poll intervals are not managed as you think. The basic
>> consideration is for the discipline loop time constant, which
>> determines the optimum poll interval. The design goal is to move it to
>> the highest value consistent with the anticipated clock frequency
>> wander. A secondary consideration is that the loop not be undersampled
>> should the timing source change. You have constrained the poll
>> interval and time constant when you specify a maxpoll for a source
>> that happens to synchronize the client and that forces all the others
>> to the same value in case one of them is selected.
>> There small gain in performance when forcing the poll interval to
>> smaller values as against letting the algorithms optimize for ambient
>> conditions. If you are trying to squeeze the optimum performance when
>> doing that, the cost is all the sources are constrained as well.
>> David J Taylor wrote:
>>> Richard B. Gilbert wrote:
>>>> The reference implementation of ntpd contributes to the deluge in a
>>>> small way! Running a Motorola Oncore as a reference clock causes my
>>>> home server to query its internet servers every 16 seconds. It's
>>>> nothing I would do by choice; they serve only as a sanity check on my
>>>> Oncore reference clock There does not appear to be any way of
>>>> turning this feature off short of modifying the code.
>>> Agreed. I would like to have my client PCs poll their two LAN
>>> servers at 64s and one Internet server at 1024s (also as a sanity
>>> check), but it seems that if any LAN server is set to 64s the
>>> Internet servers are also polled at 64s intervals.
> I realize that the poll intervals are carefully selected for optimum
> performance when only network servers are involved but do those
> considerations really require that network servers be polled every
> sixteen seconds when a GPS reference clock is the synchronization
> source? Wouldn't it be sufficient to poll the network servers
> immediately if it is considered necessary to switch synchronization
> sources? After all, they would not normally be polled at intervals of
> less than 64 seconds even if they were the sole time source!
More information about the questions