Problem solved. It was a bad network card. When I swapped cards
between two machines the problem followed the card. It's odd how the
problem only popped up when the packet size reached a certain point.
Thanks for all your help.
-
To unsubscribe from this list: send the line "unsubscribe net
Rick Jones wrote:
And if you add the test-specific -D option?
No difference. I have TCP_NODELAY in my Samba config and copying files
from the server is painfully slow. That's what got me started on all
these tests.
BTW, did someone already suggest disabling TSO if it happens to be
enable
Rick Jones wrote:
8KB socket buffers, 8KB writes to the socket or both?
8KB write to the socket with an 8KB read on the other end. TCP socket
buffers at default. I'm using netperf now since the numbers were about
the same and netperf has more options.
netperf -t TCP_STREAM -H -- -s 128K
Rick Jones wrote:
What does your quick and dirty test program use for socket buffer
sizes and/or send sizes? What does the performance look like with a
netperf TCP_STREAM test of various socket buffer and send sizes?
For my test program I used a 8K send and receive buffers. The socket
buffers
YOSHIFUJI Hideaki wrote:
What kind of NIC are you using?
All my machines here now have VIA Velocity NICs in them. The other two
machines work perfectly.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at h
Alan Cox wrote:
Should drop the packet, but it may be triggering a driver path with a
bug. Is this repeatable and with multiple 8139 cards
I took the card out of my firewall and put it into my test box. The
test procedure was to ping a third machine from the text box and then
start pinging t
Francois Romieu wrote:
Can you send lspci -vx, dmesg and lsmod after the hang ?
:00:00.0 Host bridge: VIA Technologies, Inc. VT82C693A/694x [Apollo
PRO133x] (rev c4)
Subsystem: Asustek Computer, Inc.: Unknown device 80e7
Flags: bus master, medium devsel, latency 0
