On Wed, Sep 1, 2010 at 03:43 UTC, David L. Mills <[email protected]> wrote:
Dave,
The code I wrote in ntp_monitor.c has apparently been rewritten.
Yes, I take what I like to think is credit for rewriting
ntp_restrict.c and ntp_monitor.c. I was unhappy with the way code and
structure definitions had been duplicated when IPv6 support was added,
and wanted to share more of the code between v4 and v6.
However, it was intended to be (and I believe it is) equivalent to the
original code functionally.
The MRU resolution is in seconds.
As part of the rewrite the resolution recorded in the MRU list was
changed to keep the list correctly ordered at a subsecond level and to
enable the iterative retrieval used by ntpq's mrulist command
(replacing ntpdc's monlist). However, decisions are still made based
on whole-second calculations.
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.
You seemingly claim the units of "discard minimum 0" are seconds and
that would mean zero minimum seconds between requests. The units are
log-base-2 seconds, as with minpoll and maxpoll. See the
documentation you have so lovingly maintained [1]. This was true with
the old code and remains true with the rewritten code. I have tested
4.2.6 builds on the pool server I'm involved with, and the rate
limiting behavior appears unchanged by the rewrite, except it is more
effective on a busy server where 600 monlist entries was inadequate
for rate-limiting to be enforced.
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.
The code is still there, but it is much less likely to come into play
with the 600-entry cap lifted. I also remember puzzling quite a bit
over that snippet of code and the documentation for "discard monitor"
describing it. I recall thinking the code did not appear to be doing
what the documentation stated. I welcome review of "discard monitor"
behavior in 4.2.7, where it can be made more relevant by limiting the
size of the MRU list using "mru maxdepth 100" or so.
Cheers,
Dave Hart
[1] http://www.eecis.udel.edu/~mills/ntp/html/accopt.html#discard
Dave
Dave Hart wrote:
On Wed, Sep 1, 2010 at 00:42 UTC, David L. Mills <[email protected]> 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
