[ntp:questions] [Pool] 4000 packets a second?

Dave Hart hart at ntp.org
Wed Sep 1 04:11:36 UTC 2010


On Wed, Sep 1, 2010 at 03:43 UTC, David L. Mills <mills at udel.edu> 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 <mills at 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:
>
> hart at pool1> fgrep discard /etc/ntp.conf
> # discard minimum 0 (power of 2 like poll interval) is needed
> discard minimum 0 average 3
> hart at 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
> hart at 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
> hart at pool1>
>
> A bit over 20% of incoming traffic has exceeded rate limits with
> "discard minimum 0" used (1s minimum).
>
> Cheers,
> Dave Hart
>
>



More information about the questions mailing list