[ratelimits] results of responses/sec, slip and window size settings

Vernon Schryver vjs at rhyolite.com
Fri May 10 13:59:31 UTC 2013

> From: =?ISO-8859-1?Q?Gergely_B=E1cskai?= <mor.mango at gmail.com>

> I set the RRL's window size to 5, responses-per-second to 5, and just for
> sure, slip to 2.
> I have sent 1000 queries to the server with the queryperf script.
> The results are:
> 1000 queries, runtime: 131,8 sec, -->7.58 queries/sec
> ~50% success  ->3.8 successful queries/sec
> My two questions are:
> -how does the window size=5 affect in this example? (I've tried it with
> window=1, and got almost the same results, 57% success...)

There is this text for the ARM:

  Rate limiting uses a "credit" or "token bucket" scheme. Each
  identical response has a conceptual account that is given
  responses-per-second, errors-per-second, and nxdomains-per-second
  credits every second. A DNS request triggering some desired
  response debits the account by one. Responses are not sent while
  the account is negative. The account cannot become more positive
  than the per-second limit or more negative than window times the
  per-second limit. A DNS client that sends requests that are not
  answered can be penalized for up to window seconds (default 15).

> -Shouldn't it act like:
> "I have 1000 queries, 131.8 sec runtime, so because of the
> responses-per-sec=5, every second it should be at first 5 successful
> queries -->5x131.8=659 successful queries at all minimum.
> But because of the slip=2, every second query of the rest 1000-659=341
> (about 170 queries) should be also successful.
> So at all, it should be 170+659=859 successful queries out of 1000?"
> ...And I don't even know how to count the window=5 for this....

Were all of the queries identical?

Does queryperf count "slipped" or truncated (TC=1) responses as
"successful"?  Does querfyperf react to truncated responses by
retrying with TCP?
I suspect queryperf is doing at least some retrying and delaying
for responses before sending more queries because 8 queries/second
is too slow for hardware made in this century.

A test that sends 1000 queries in one second should receive 5 normal
response followed by 497 or 498 "slipped" or truncated (TC=1)

The only good way I can see to answer such questions is to configure
BIND9 logging for the "queries" and "rate-limit" categories with a
debug level of at least 1, and look.  That will tell when BIND received
each query and what did.

Vernon Schryver    vjs at rhyolite.com

More information about the ratelimits mailing list