UDP packet loss

[Scott S. Bertilson]

> Rick Jones wrote:
> > Patrick Klos <pklos at osmium.mv.net> wrote:
> > 
> >> I'd say your biggest problem is the 214 million packet receive
> >> errors!  Find the source of those errors, and you'll likely take
> >> care of your problem.  Your machine is tossing 1 out of every 4 or 5
> >> packets!
> > 
> > IIRC, 99 times out of 10 those packet receive errors are the socket
> > buffer overflowing.
> > 
> > Now, to actually get a larger socket buffer, you may need to tweak the
> > sysctl settings _and_ something in the named config file.  Sysctl to
> > raise the limit and named config file to make sure that named doesn't
> > "undo" it by asking for something smaller.
> > 
> > However, that will only help if the issue is occasional bursts of
> > requests and the average request rate remains within the limits of the
> > server.  If the average request rate is higher than the server can
> > satisfy, no increase in the socket buffer will help.
> > 
> > rick jones
> 
> That's what I thought. I just need to know what to change on Bind level. 
> Operating system keeps this limit OK, but I don't know if Bind is 
> actually using it. I don't think that hardware couldn't keep up with 
> traffic (processors are at least 20% idle), about 4GB ram free etc, but 
> maybe there is something more to tweak. Suggestions, anyone?

You can get an idea of what the socket buffer size is
if you can catch the system at a time when the "packet
receive error" counter is ticking along by:
    netstat -na --inet | grep ':53 '
You'll likely see a TCP port 53 socket, but its Recv-Q
is likely small or 0 unless you're receiving a very
large number of TCP queries (a very unusual situation).
On the other hand, you should see a fairly large number
in a UDP port 53 Recv-Q.  If you're overflowing, that
number will probably be very close to the UDP socket
input queue size for that socket.
				Scott