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]
Message-ID: <48F7AD1A.7050309@hp.com>
Date:	Thu, 16 Oct 2008 14:07:38 -0700
From:	Rick Jones <rick.jones2@...com>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	netdev@...r.kernel.org, bugme-daemon@...zilla.kernel.org,
	arno@...o.snv.jussieu.fr, Ayaz Abdulla <aabdulla@...dia.com>
Subject: Re: [Bugme-new] [Bug 11752] New: Extremely low netperf UDP_RR	throughput
 for nvidia MCP65

Andrew Morton wrote:
> (switched to email.  Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
> 
> On Mon, 13 Oct 2008 13:41:19 -0700 (PDT)
> bugme-daemon@...zilla.kernel.org wrote:
> 
> 
>>http://bugzilla.kernel.org/show_bug.cgi?id=11752
>>
>>           Summary: Extremely low netperf UDP_RR throughput for nvidia MCP65
>>           Product: Drivers
>>           Version: 2.5
>>     KernelVersion: from F10-Beta-x86_64-Live-KDE.iso
>>          Platform: All
>>        OS/Version: Linux
>>              Tree: Mainline
>>            Status: NEW
>>          Severity: normal
>>          Priority: P1
>>         Component: Network
>>        AssignedTo: jgarzik@...ox.com
>>        ReportedBy: arno@...o.snv.jussieu.fr
>>
>>
>>Latest working kernel version: -
>>Earliest failing kernel version:
>>Distribution: F10-Beta-x86_64
>>Hardware Environment: HP Pavillon dv6820ef
>>Software Environment:
>>Problem Description: when running at 1Gbps netperf shows good performance for
>>TCP_STREAM and UDP_STREAM tests, but extremely bad performance for UDP_RR test
>>(less then 1 ping-pong a second whereas at 100Mbps performance easily reaches
>>10-20K a second)
>>
>>A friend figured out that it looks like small packets at 1Gbps are dropped
>>as being falsely considered crc-errored.

Given how netperf UDP_RR has _no_ recovery from lost datagrams, it makes 
sense that performance on that test would be very low - the first lost 
datagram the transactions come to a screeching halt until the 
end-of-test timer expires.

Are netstat stats showing retransmissions during a TCP_STREAM test?  How 
about a TCP_RR test?  TCP_RR might be low too, it just wouldn't 
necessarily be as low since TCP will get things started again after a 
loss.   UDP_STREAM would just go blasting along without a care in the 
world...

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ