From: Ion Badulescu <ionut@cs.columbia.edu>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: linux-kernel@vger.kernel.org,
cfriesen@nortelnetworks.com (Chris Friesen)
Subject: Re: want opinions on possible glitch in 2.4 network error reporting
Date: Wed, 6 Feb 2002 20:51:04 -0500 [thread overview]
Message-ID: <200202070151.g171p4h11574@moisil.badula.org> (raw)
In-Reply-To: <E16YcOK-0006wT-00@the-village.bc.nu>
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.
next prev parent reply other threads:[~2002-02-07 1:54 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-02-06 20:31 Chris Friesen
2002-02-06 20:56 ` Richard B. Johnson
2002-02-06 21:45 ` Ben Greear
2002-02-06 22:23 ` Chris Friesen
2002-02-07 13:44 ` Richard B. Johnson
2002-02-07 16:33 ` Gerold Jury
2002-02-07 0:24 ` Alan Cox
2002-02-07 0:26 ` Alan Cox
2002-02-07 1:51 ` Ion Badulescu [this message]
2002-02-07 2:08 ` Alan Cox
2002-02-07 2:09 ` Ion Badulescu
2002-02-07 2:34 ` Alan Cox
2002-02-07 2:54 ` Ion Badulescu
2002-02-07 11:11 ` Alan Cox
2002-02-08 16:11 ` Pavel Machek
2002-02-08 21:39 ` Ion Badulescu
2002-02-07 4:21 ` Ben Greear
2002-02-07 4:38 ` David S. Miller
2002-02-07 4:56 ` Ben Greear
2002-02-07 4:23 ` Ben Greear
2002-02-07 4:37 ` Ion Badulescu
2002-02-07 9:22 ` Luis Garces
[not found] <3C6192A5.911D5B4F@nortelnetworks.com.suse.lists.linux.kernel>
2002-02-07 0:06 ` Andi Kleen
2002-02-07 15:59 ` Chris Friesen
2002-02-07 16:01 ` Andi Kleen
[not found] <E16Ydys-0007D6-00@the-village.bc.nu.suse.lists.linux.kernel>
[not found] ` <Pine.LNX.4.44.0202062101390.4832-100000@age.cs.columbia.edu.suse.lists.linux.kernel>
2002-02-07 2:47 ` Andi Kleen
2002-02-07 6:25 ` Chris Friesen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200202070151.g171p4h11574@moisil.badula.org \
--to=ionut@cs.columbia.edu \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=cfriesen@nortelnetworks.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®