On Thu, 7 Feb 2002 00:26:20 +0000 (GMT), Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> I ran into a somewhat related issue on a 2.2.16 system, where I had an app that
>> was calling sendto() on 217000 packets/sec, even though the wire could only
>> handle about 127000 packets/sec. I got no errors at all in sendto, even though
>> over a third of the packets were not actually being sent.
>
> That is correct UDP behaviour
This is totally untrue, unless the socket doing non-blocking I/O -- and
even then you get -1 and EAGAIN from sendto.
Otherwise sendto is very much a blocking operation which will block until
there is enough space in socket buffer to store the data. From there,
there is no way to "lose" that data before it hits the wire, unless of
course the network driver is broken and doesn't plug the upper layers when
its TX queue is full.
Think of it: if what you said were true, NFS over UDP would be totally
useless. But it's not, so if UDP data gets lost before it hits the wire,
it's usually a bug in the network driver.
>From the limited testing I just ran, I appears that starfire and 3c59x
handle this correctly, whereas tulip always loses a small number of
packets during a UDP storm. ttcp -us[rt] is very useful for such
testing...
Ion
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Feb 07 2002 - 21:00:56 EST