Re: Network compatibility and performance

From: linux-os (Dick Johnson)
Date: Thu Aug 10 2006 - 14:07:17 EST

On Thu, 10 Aug 2006, Stephen Hemminger wrote:

> On Thu, 10 Aug 2006 11:34:23 -0400
> "linux-os \(Dick Johnson\)" <linux-os@xxxxxxxxxxxx> wrote:
>> Hello,
>> Network throughput is seriously defective with linux-
>> if the length given to 'write()' is a large number.
>> Given this code on a connected socket........
> What protocol (TCP?) and what Ethernet hardware (does it support TSO)?
> Did you set non-blocking?

A connected TCP socket. The Ethernet hardware was also
described (Intel using e1000 as shown) It's on PCI-X 133MHz, two
devices on the motherboard, not really relevent because it worked
previously as described. TSO? No ARPA virtual terminals here.
They went away in 1972. The socket was set to non-blocking because the
same socket is used for reading (not at the same time), using poll()
to find when data are supposed to be available. BTW, read() code
used to use poll() to find out when data were available, but if
poll returned POLLIN, sometimes data would NOT be available and
the code would hang <forever>. Therefore a work-around was to set
the socket non-blocking. Under the conditions where poll() would
return POLLIN and a read of a non-blocking socket returned no data,
the errno was 3 (no such process) which seems really strange.
Nevertheless, this has worked in the field for quite some time.

There are no threads or child processes sharing data. Just a
task receiving messages (commands) and then sending data (responses).
Nothing in any user code overlaps.

Dick Johnson
Penguin : Linux version on an i686 machine (5592.62 BogoMips).
New book:

The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@xxxxxxxxxxxx - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at