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

David L. Mills mills at udel.edu
Wed Sep 1 19:40:35 UTC 2010


Dave,

Looks like you got impaled on my own bug. The intent was indeed to 
express the minimum headway, aka guard time (ntp_minpkt), in seconds, 
not as exponent. This is so folks could specify 3 s, for instance. This 
is what the configuration code assumes. On the other hand, the minimum 
average headway (ntp_minpoll) is specified as an exponent of two, since 
this is consistent with poll interval. Both of these items are used 
elsewhere in the rate management code. However, and it must by my bug, I 
mistakenly coded it in ntp_monitor.c and ntp_proto.c as exponent. We can 
discuss offline how to fix this simple bug. Apparently, I never did get 
around to documenting the command other than an orphan reference on the 
rate management page. That's in process of fix.

Dave

Dave Hart wrote:

>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