Re: Loosing UDP packets...

Rick Jones wrote:
googlegroups@xxxxxxxxxx wrote:
1) EWOULDBLOCK never comes up true. The stack is always willing to
take your UDP data, regardless of ability to get datagrams down to the
wire.

My netperf-based experience is that for a _blocking_ socket,
intra-stack flow-control gets excerted. I "never" see UDP_STREAM rates
greater than link-rate under Linux.

The applications I support send lots (> 100Mb/s) of UDP via
non-blocking sockets. Sometimes all the packets hit the wire,
sometimes they dont.

When data is lost, I've observed 2 things:
1) no EWOULDBLOCK
2) the inter-packet timing / packetrate remains fairly constant, but
there are huge (50+) packet holes in the UDP "stream" (I know it's not
a stream, but the packets are sequenced at the application layer) --
data is being accepted by the stack at a different rate than it's
leaving the NIC.

poking through kernel code found a comment to the effect of "well, udp
is unreliable anyway, and this is easier..."

2) silent overflows of the txqueue buffer. You can lose data here,
and there's nothing you can do about it, nor can you see it
happening.

Perhaps that is only for a non-blocking socket - per my stuff above?

Don't think so, but not sure. the txqueue is getting pretty close to
layer 2.

Solaris has neither of these problems. If the stack accepts your
datagram, it will make it to the wire.

Is it _really_ that absolute? I can think of some possible holes:

Perhaps I've overstated the case a bit :-)

1) Your send is the first to a given IP and that IP has no ARP entry
and ARP resolution fails

This is indeed a hole. Solaris arp holds 4 packets. Linux holds 3 (by
default). Static entries here are (becoming) standard practice for my
high datarate UDP stuff on both platforms.

2) There is a transmission error

I suppose "an error" could occur anywhere :-)

Is there a check that there is a route to the destination before the
sendto() call completes?

Hrm. I don't know. Most of my experience falls into:
a) local segment receivers (the route is always there)
b) broadcast (no route needed)
c) multicast (no route -- i've bound to a NIC)

How about if the datagram has to be fragmented - does the Solaris
stack "guarantee" that all fragments of the datagram will be
transmitted?

I don't know, as I don't send > MTU datagrams.

Still, as a practical matter, Linux tends to drop my data on its way
out of the box. Silently spilling data off the top of a full socket
buffer is particularly annoying. It's dropping the OP's data too.

I didn't mean to start a religious battle. I mentioned Solaris only
because it's the other main platform where I support those
applications, and It's been so much nicer to my data.

/chris

.

Relevant Pages