netdev - Re: [Bugme-new] [Bug 11752] New: Extremely low netperf UDP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 20 Oct 2008 10:41:21 -0700
From:	Rick Jones <rick.jones2@...com>
To:	"Arno J. Klaassen" <arno@...o.snv.jussieu.fr>
CC:	Andrew Morton <akpm@...ux-foundation.org>, netdev@...r.kernel.org,
	bugme-daemon@...zilla.kernel.org,
	Ayaz Abdulla <aabdulla@...dia.com>
Subject: Re: [Bugme-new] [Bug 11752] New: Extremely low	netperf	UDP_RR	throughput
 for nvidia MCP65

>>Clearly something is fubar with the rx side (well duh :).  The next
>>set of stats I'd try to look at would be ethtool stats for the
>>interface, eg ethtool -S eth0 and see if it shows someting more
>>specific for the "RX-ERR" shown by netstat -I eth0.
> 
> 
> OK, here it is (rx_errors_total: 10049, rx_crc_errors: 10049) :

Well, that seems to confirm that it is CRC errors.  Did your friend say 
why he thought they were false CRC errors?

If indeed it is only small packets/frames getting the CRC errors, in 
_theory_ a TCP_RR test with a larger request/response size should show 
"good" performance because there should be few if any standalone ACKs. 
You could start with something like:

netperf -H <remote> -t TCP_RR -- -r 1448

and work your way down, checking for those CRC errors as you go.  I 
don't thnik folks need all the output, just some idea of if you still 
see CRC errors with full-size TCP_RR and if you don't at what size you 
start to see them.  I picked 1448 to have the request and response both 
result in a "full" TCP segment assuming an MTU of 1500 bytes and 
timestamps being enabled. (net.ipv4.tcp_timestamps).

Has the usual litany of cable swapping and such been done already?  A 
cable *known* to be good at 1G swapped-in and such?  If this is via a 
switch, just for completeness trying other switch ports etc etc.

While I'd not expect it to be at 1Gig and autoneg, CRC errors can 
sometimes be a sign of a duplex mismatch, but I have a difficult time 
seeing that happening - unless there happens to be other traffic on the 
link a plain netperf TCP_RR or UDP_RR test should "never" have both 
sides trying to talk at the same time and so shouldn't trip-over a 
duplex mismatch like a TCP_STREAM test would.

> (NB, let me know how to eventually test eventual patches/binary
> modules on a life-CD; I've just limited linux kernel skills)

I'm going to have to defer to others on that score.  Meanwhile some 
additional information gathering:

For grins and bugzilla posterity, ethtool -i <interface> would be 
goodness. What was the last "known good" configuration?  What is running 
"on the other side?" etc etc.  Does say some other or earlier distro 
(Fedora, Ubuntu whatnot) Live CD not exhibit this problem?  If not, what 
are the kernel and ethtool -i information from that?

rick jones
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html