request drops in BIND?

[Rick Jones]

KyoungSoo Park <kyoungso at cs.princeton.edu> wrote:
> BIND's default recv buffer size is max(32KB, default buffer), and in
> the box I tested, it's 64KB.  Each request is about 64 bytes
> including header(UDP/IP), so the recv buffer should be big enough to
> hold all requests.

That "depends" - the driver will, likely as not, have allocated a full
link-MTU-sized buffer for the inbound DMA.  There is no a priori
knowledge of an inbound packet size, so most simple card/driver models
have a buffer of MTU sized being posted for DMA (yes, there can be
more sophisticated schemes :)

So, over Ethernet that could be a 1500ish byte buffer - and if the
system is using a power-of-two allocator, that would be a 2048 byte
buffer.

All to hold your 64 byte request.

Now... if the stack tracks not just actual data bytes, but also
"overhead bytes" your 200, 64 byte requests could be counting as
O(400KB) (200 * 2048) of space and could indeed be overflowing the
socket buffer if they arrive in a spike faster than the named can
process them.

Some stacks have statistics for UDP socket buffer overflows - you
might look at netstat output for some variation on netstat options.
That would also be a place to look for drops of the responses by the
client program.

I suppose if you wanted to eliminate socket buffer overflow as a
possiblity, you might make the default on your system ridiculously
large - say 1 GB or something.  Then run your test again.

Drifting a bit since you asserted that tcpdump showed all the requests
arriving at the server... but for the sake of completeness...

...there can be limits on the outbound transmit queues for the NIC.
Ostensibly, there should be a way to retrieve link-level statistics
from your systems to see if perhas the transmit queues have been
overflown/overflowed.

rick jones
-- 
denial, anger, bargaining, depression, acceptance, rebirth...
                                     where do you want to be today?
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to raj in cup.hp.com  but NOT BOTH...