Rafal Boni writes:
>         I realize that UDP is an inherently unreliable protocol, but should
>         the kernel be dropping UDP packets so soon?  I don't see this happen
>         when I use the HP9k, Sparc or RS6k as the sending piece of the link..

John F. Woods writes:
> I think you're not looking hard enough if you don't see it on those machines.

> There is no flow control mechanism available for UDP, and by convention
> a write to a UDP socket when the output device is jammed discards the packet;
> the kernel is willing to queue up some small number of mbufs on an OACTIVE
> interface (usually 50, see IFQ_MAXLEN in /sys/net/if.[ch]), and after that,
> they go on the floor.  An HP9000 should *certainly* be able to create UDP
> packets faster than they can be transmitted, and I know that I've seen Sparcs
> do that (with ttcp, even).

As John says, this is the normal behavior on output queue
being full.  If you are not seeing this behavior on some
other machine with ttcp/udp, it can mean one or more of:
a) netstat is broken, b) the driver is not counting dropped
packets, c) ttcp is broken or d) operator error.

The way ttcp handles this error is by delaying for 18
milliseconds on seeing an ENOBUF error from a udp sendto().
Give this delay you should not see more than 55
errors/second for large size packets (and much less for
small ones).  If you are seeing more than 55 errors/second,
most likely cause is one of a) select times out quicker than
18ms, b) the kernel/driver returns something other than
ENOBUF when it runs out buffers, c) ttcp is broken, d)
netstat is broken or e) operator error.

Whatever you do, please don't change ttcp's 18ms time delay
constant (or at any rate, don't let loose that version)!  By
now it is a pretty standard tool for measuring `guaranteed
not to exceed' throughput numbers.  Also, make sure you have
the correct ttcp (ftp from sgi.com).

Bakul