Dave,
The code I wrote in ntp_monitor.c has apparently been rewritten. The MRU
resolution is in seconds. The original interpretation of minimum was
that any headway less than this would be dropped. Setting that to zero
would mean nothing would be dropped. Apparently, the current code is
contrary to the original intent and documentation.
I didn't check to see if the probabilistic choice to preempt old entries
if the list is full remains. My earlier experience is that this is
important for the busiest servers.
Dave
Dave Hart wrote:
On Wed, Sep 1, 2010 at 00:42 UTC, David L. Mills <mi...@udel.edu> wrote:
Did you intend the discard minimum 0? That effectively disables the rate
control defense mechanism. you should leave it out.
That has not been my experience on the pool server I'm involved with:
h...@pool1> fgrep discard /etc/ntp.conf
# discard minimum 0 (power of 2 like poll interval) is needed
discard minimum 0 average 3
h...@psp-fb1> ntpq -c sysstats
uptime: 1059862
sysstats reset: 1059862
packets received: 263004216
current version: 144454930
older version: 99867648
bad length or format: 18635251
authentication failed: 316799
declined: 3179
restricted: 14857
rate limited: 56970859
KoD responses: 1405175
processed for time: 76220
h...@pool1> ntpdc -c sysstats
time since restart: 1059868
time since reset: 1059868
packets received: 263005578
packets processed: 76220
current version: 144455895
previous version: 99867947
declined: 3179
access denied: 14857
bad length or format: 18635348
bad authentication: 316800
rate exceeded: 56971000
h...@pool1>
A bit over 20% of incoming traffic has exceeded rate limits with
"discard minimum 0" used (1s minimum).
Cheers,
Dave Hart
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
