Hi there,

My understanding is that given reliable transmission (ie no tx buffer overrun), UDP packets may be lost on three levels:

1. On the wire if your ethernet is suspect.
2. In the ethernet driver if there are not enough Rx buffer descriptors.
3. In the IP stack if the UDP socket buffers are to small and not serviced fast enough by your application.

My question is how do you reliably tell where packets get lost?

netstat -su will give you packet receive errors

This supposedly is an indication of the number of packets lost by means of (3).

I have a very good ethernet, but maybe packets are lost in my switch? How to detect this?

I have a good ethernet device (Intel e1000) and driver with 4096 rx buffer descriptors. How do I detect buffer overrun?

Is netstat -su a reliable counter for socket buffer overrun?

Regards

I dont' understand why you're trying to use UDP when what you
want are features of TCP. UDP is by definition connection-
less and doesn't implement those checks.


Cheers,
Tink

There are reasons to use UDP instead of TCP.

1. The source of the UDP data is an embedded device streaming data at a steady rate of up to 256Mb/s over gigabit ethernet as 128 streams of UDP datagrams. The device does not have the resources to do this using TCP.

2. The data flows over gigE LAN as follows: Device -> switch -> Consumer (High-end Linux server). Technically if there are no significant additional traffic switched to the Consumer, and the Consumer processes the UDP frames fast enough it should all work fine. This is the case most of the time.

I have configured 1 second worth of buffering per UDP socket receiving each one of the above mentioned UDP streams. Once every couple of hours there seems to be a glitch where upto a couple of hundred frames are lost (I know this since I put sequence nrs in the UDP packets).

I am simply trying to find out if there is an easy way to check whether I have overrun in my socket buffers. Increasing the buffers might alter my results but it is not conclusive.

Regards