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

[Gergely Bácskai]

Yep, all queries were identical.
I've read some documentation of the queryperf, it's a DNS-server
performance measuring tool, shipped with BIND (as I know).
>From this info I think the "query/sec" was low because of my virtualbox,
but I'm not sure about this..

...but this should not affect the count of success/failure. As I know,
queryperf does not respond to the truncated responses. I'm not sure if it
counts these as "successful responses", I'll look after it.
I have set the logging in my BIND server, but the only log related to RRL I
could find is in the "/var/log/named/bind-queries.log"

I've made another try with 10 queries, and the RRL settings were: slip=2,
resposnses-per-second=5, window=5, I've attached the results on 2 images:
one is the queryperf result, and the other one is the bind-queries.log part
of my action. Can somebody tell me from the attached bind log, how many
queries were successful of the 10, so I can correlate it with the queryperf
result?

(Or maybe could anybody suggest a method that I can use to get the
"expected" results of the mentioned RRL-settings?)

Thanks,
Greg


2013/5/10 Vernon Schryver <vjs at rhyolite.com>

> > 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)
> responses.
>
> 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
> _______________________________________________
> ratelimits mailing list
> ratelimits at lists.redbarn.org
> http://lists.redbarn.org/mailman/listinfo/ratelimits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.redbarn.org/pipermail/ratelimits/attachments/20130514/82a708a2/attachment.html>