Re: request drops in BIND?

Hi,

>It doesn't matter. your responses are making no demands on the system for
>looking up
>and finding information. The only relationship is the roundtrip time. The
>time taken to
>process the request is what you need to think about.
>
>
Yes. Absolutely. BIND cannot be faster than PING, but it has no reason
to not respond
to such a low rate request(200 reqs/sec at burst). What I see is slient
response dropping from the BIND
not the absoulte speed difference between BIND and PING.

All I did was to ask for one local domain name consistently.
For each request, the id is set differently, so I expect every response
to every request.
But all I see is 178 responses out of 200 requests, while PING respond
to all under the same situation.
Why? 200 requests don't fill up the UDP receive buffer, and also it
doesn't fill up the send buffer either.
(So, it's not a kernel(UDP stack) problem)
I think there's something stupid going on in the source code, silently
dropping not even leaving
a trace in the debug trace.

>Your message didn't specify the difference. I assume you meant what's in
>the BIND code.
>I don't remember what the default size is in socket.c, however, that buffer
>is per request.
>
>
Sorry about that. But even if the UDP buffer is usedonly for getting
requests, given that the
request size is 64 bytes, 1024 requests or more at any point would
overflow the buffer.
My point was that it's too easy that BIND even cannot see the requests
simply because its
receive buffer is too small. But I'm not saying this is the cause for
the problem in my experiment.

>Yes, but if you are concerned about the buffers filling up before it has a
>chance to process
>the request, it's easy to added IP addresses and thereby have more buffer
>available in
>BIND.
>
>
Yes. But, still the current buffer size is too small. At any time, if
BIND is blocking for some reason,
it would be easily filled up even for just reasonable size of clients. A
single drop of request will eventually
lead to five seconds of delay even for the cached item. (five seconds =
default retransmission timeout
of BIND resolver)

>Did you build multithreaded or singlethreaded? Is it a single CPU or multi-CPU?
>How much memory does the machine have? How many domain records? Are the
>queries for records for which the server is authorative or does it need to make
>recursive queries if the answers are not in cache?
>
>Yes the debug trace is complex and is unlikely to be easy for you to understand
>especially if it's multithreaded. What is needed is to be able to look at
>the various
>queues to see what they're doing.
>
>
It's a single CPU, 1 GB memory. It's not authoritative for any names.
It's set up mainly for the experiment that I described. I issue only one
domain name lookup whose
TTL is one day. So, the record should be in the memory , thus fetched
instantly.

About the debug trace, it seems it's not for public review purpose. But
it seems it's saying it's handling only
178 requests. But I don't know if it drops requests(no sign of saying
"dropping") silently or simply
cannot see the requests.

Thanks,
KyoungSoo