From: Rick Jones <rick.jones2@hp.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: netdev@vger.kernel.org, bugme-daemon@bugzilla.kernel.org,
arno@heho.snv.jussieu.fr, Ayaz Abdulla <aabdulla@nvidia.com>
Subject: Re: [Bugme-new] [Bug 11752] New: Extremely low netperf UDP_RR throughput for nvidia MCP65
Date: Thu, 16 Oct 2008 14:07:38 -0700 [thread overview]
Message-ID: <48F7AD1A.7050309@hp.com> (raw)
In-Reply-To: <20081016134920.1492cdcc.akpm@linux-foundation.org>
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@bugzilla.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@pobox.com
>> ReportedBy: arno@heho.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
next prev parent reply other threads:[~2008-10-16 21:07 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <bug-11752-10286@http.bugzilla.kernel.org/>
2008-10-16 20:49 ` [Bugme-new] [Bug 11752] New: Extremely low netperf UDP_RR throughput for nvidia MCP65 Andrew Morton
2008-10-16 21:07 ` Rick Jones [this message]
2008-10-17 14:28 ` Arno J. Klaassen
2008-10-17 20:49 ` Arno J. Klaassen
2008-10-17 21:05 ` Rick Jones
2008-10-18 11:36 ` Arno J. Klaassen
2008-10-20 17:41 ` Rick Jones
2008-10-31 13:07 ` Arno J. Klaassen
2008-12-11 20:53 ` Arno J. Klaassen
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=48F7AD1A.7050309@hp.com \
--to=rick.jones2@hp.com \
--cc=aabdulla@nvidia.com \
--cc=akpm@linux-foundation.org \
--cc=arno@heho.snv.jussieu.fr \
--cc=bugme-daemon@bugzilla.kernel.org \
--cc=netdev@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;
as well as URLs for NNTP newsgroup(s).