From: Rick Jones <rick.jones2@hp.com>
To: Larry McVoy <lm@bitmover.com>
Cc: David Miller <davem@davemloft.net>,
torvalds@linux-foundation.org, herbert@gondor.apana.org.au,
wscott@bitmover.com, netdev@vger.kernel.org
Subject: Re: tcp bw in 2.6
Date: Tue, 02 Oct 2007 15:59:52 -0700 [thread overview]
Message-ID: <4702CD68.8090406@hp.com> (raw)
In-Reply-To: <20071002223644.GA14331@bitmover.com>
Larry McVoy wrote:
> On Tue, Oct 02, 2007 at 03:32:16PM -0700, David Miller wrote:
>
>>I'm starting to have a theory about what the bad case might
>>be.
>>
>>A strong sender going to an even stronger receiver which can
>>pull out packets into the process as fast as they arrive.
>>This might be part of what keeps the receive window from
>>growing.
>
>
> I can back you up on that. When I straced the receiving side that goes
> slowly, all the reads were short, like 1-2K. The way that works the
> reads were a lot larger as I recall.
Indeed I was getting more like 8K on each recv() call per netperf's -v 2 stats,
but the system was more than fast enough to stay ahead of the traffic. On the
hunch that it was the interrupt throttling which was keeping the recv's large
rather than the speed of the system(s) I nuked the InterruptThrottleRate to 0
and was able to get between 1900 and 2300 byte recvs on the TCP_STREAM and
TCP_MAERTS tests and still had 940 Mbit/s in each direction.
hpcpc106:~# netperf -H 192.168.7.107 -t TCP_STREAM -v 2 -c -C
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.7.107
(192.168.7.107) port 0 AF_INET
Recv Send Send Utilization Service Demand
Socket Socket Message Elapsed Send Recv Send Recv
Size Size Size Time Throughput local remote local remote
bytes bytes bytes secs. 10^6bits/s % S % S us/KB us/KB
87380 87380 87380 10.02 940.95 10.75 21.65 3.743 7.540
Alignment Offset Bytes Bytes Sends Bytes Recvs
Local Remote Local Remote Xfered Per Per
Send Recv Send Recv Send (avg) Recv (avg)
8 8 0 0 1.179e+09 87386.29 13491 1965.77 599729
Maximum
Segment
Size (bytes)
1448
hpcpc106:~# netperf -H 192.168.7.107 -t TCP_MAERTS -v 2 -c -C
TCP MAERTS TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.7.107
(192.168.7.107) port 0 AF_INET
Recv Send Send Utilization Service Demand
Socket Socket Message Elapsed Send Recv Send Recv
Size Size Size Time Throughput local remote local remote
bytes bytes bytes secs. 10^6bits/s % S % S us/KB us/KB
87380 87380 87380 10.02 940.82 20.44 10.61 7.117 3.696
Alignment Offset Bytes Bytes Recvs Bytes Sends
Local Remote Local Remote Xfered Per Per
Recv Send Recv Send Recv (avg) Send (avg)
8 8 0 0 1.178e+09 2352.26 500931 87380.00 13485
Maximum
Segment
Size (bytes)
1448
the systems above had four 1.6 GHz cores, netperf reports CPU as 0 to 100%
regardless of core count.
and then my systems with the 3.0 GHz cores:
[root@s9 netperf2_trunk]# netperf -H sweb20 -v 2 -t TCP_STREAM -c -C
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to sweb20.cup.hp.com
(16.89.133.20) port 0 AF_INET
Recv Send Send Utilization Service Demand
Socket Socket Message Elapsed Send Recv Send Recv
Size Size Size Time Throughput local remote local remote
bytes bytes bytes secs. 10^6bits/s % S % S us/KB us/KB
87380 16384 16384 10.03 941.37 6.40 13.26 2.229 4.615
Alignment Offset Bytes Bytes Sends Bytes Recvs
Local Remote Local Remote Xfered Per Per
Send Recv Send Recv Send (avg) Recv (avg)
8 8 0 0 1.18e+09 16384.06 72035 1453.85 811793
Maximum
Segment
Size (bytes)
1448
[root@s9 netperf2_trunk]# netperf -H sweb20 -v 2 -t TCP_MAERTS -c -C
TCP MAERTS TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to sweb20.cup.hp.com
(16.89.133.20) port 0 AF_INET
Recv Send Send Utilization Service Demand
Socket Socket Message Elapsed Send Recv Send Recv
Size Size Size Time Throughput local remote local remote
bytes bytes bytes secs. 10^6bits/s % S % S us/KB us/KB
87380 16384 16384 10.03 941.35 12.13 5.80 4.221 2.018
Alignment Offset Bytes Bytes Recvs Bytes Sends
Local Remote Local Remote Xfered Per Per
Recv Send Recv Send Recv (avg) Send (avg)
8 8 0 0 1.181e+09 1452.38 812953 16384.00 72065
Maximum
Segment
Size (bytes)
1448
rick jones
next prev parent reply other threads:[~2007-10-02 22:59 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20070929142517.EC6AB5FB21@work.bitmover.com>
[not found] ` <alpine.LFD.0.999.0709290914410.3579@woody.linux-foundation.org>
[not found] ` <20070929172639.GB7037@bitmover.com>
[not found] ` <alpine.LFD.0.999.0709291050200.3579@woody.linux-foundation.org>
2007-10-02 0:59 ` tcp bw in 2.6 Larry McVoy
2007-10-02 2:14 ` Linus Torvalds
2007-10-02 2:20 ` Larry McVoy
2007-10-02 3:50 ` David Miller
2007-10-02 4:23 ` Larry McVoy
2007-10-02 15:06 ` John Heffner
2007-10-02 17:14 ` Rick Jones
2007-10-02 17:20 ` Larry McVoy
2007-10-02 18:01 ` Rick Jones
2007-10-02 18:40 ` Larry McVoy
2007-10-02 19:47 ` Rick Jones
2007-10-02 21:32 ` David Miller
2007-10-03 7:19 ` Bill Fink
2007-10-02 10:52 ` Herbert Xu
2007-10-02 15:09 ` Larry McVoy
2007-10-02 15:41 ` Larry McVoy
2007-10-02 16:25 ` Larry McVoy
2007-10-02 16:47 ` Stephen Hemminger
2007-10-02 16:49 ` Larry McVoy
2007-10-02 17:10 ` Stephen Hemminger
2007-10-15 12:40 ` Daniel Schaffrath
2007-10-15 15:49 ` Stephen Hemminger
2007-10-02 16:34 ` Linus Torvalds
2007-10-02 16:48 ` Larry McVoy
2007-10-02 21:16 ` David Miller
2007-10-02 21:26 ` Larry McVoy
2007-10-02 21:47 ` David Miller
2007-10-02 22:17 ` Rick Jones
2007-10-02 22:32 ` David Miller
2007-10-02 22:36 ` Larry McVoy
2007-10-02 22:59 ` Rick Jones [this message]
2007-10-03 8:02 ` David Miller
2007-10-02 16:48 ` Ben Greear
2007-10-02 17:11 ` Larry McVoy
2007-10-02 17:18 ` Ben Greear
2007-10-02 17:21 ` Larry McVoy
2007-10-02 17:54 ` Stephen Hemminger
2007-10-02 18:35 ` Larry McVoy
2007-10-02 18:29 ` John Heffner
2007-10-02 19:07 ` Larry McVoy
2007-10-02 19:29 ` Linus Torvalds
2007-10-02 20:31 ` David Miller
2007-10-02 19:33 ` Larry McVoy
2007-10-02 19:53 ` John Heffner
2007-10-02 20:14 ` Larry McVoy
2007-10-02 20:40 ` Rick Jones
2007-10-02 20:42 ` Wayne Scott
2007-10-02 21:56 ` Linus Torvalds
2007-10-02 19:27 ` Linus Torvalds
2007-10-02 19:53 ` Rick Jones
2007-10-02 20:33 ` David Miller
2007-10-02 20:44 ` Roland Dreier
2007-10-02 21:21 ` Larry McVoy
2007-10-03 21:13 ` Pekka Pietikainen
2007-10-03 21:23 ` Larry McVoy
2007-10-03 21:50 ` Pekka Pietikainen
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=4702CD68.8090406@hp.com \
--to=rick.jones2@hp.com \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=lm@bitmover.com \
--cc=netdev@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=wscott@bitmover.com \
/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).