[netperf-dev] netperf2 commit notice r435 - in trunk/doc: . examples
raj at netperf.org
raj at netperf.org
Fri Jul 15 16:20:40 PDT 2011
Author: raj
Date: 2011-07-15 16:20:40 -0700 (Fri, 15 Jul 2011)
New Revision: 435
Added:
trunk/doc/examples/runemomni.sh
trunk/doc/examples/runemomniagg2.sh
Modified:
trunk/doc/netperf.html
trunk/doc/netperf.info
trunk/doc/netperf.pdf
trunk/doc/netperf.texi
trunk/doc/netperf.txt
Log:
doc updates
Added: trunk/doc/examples/runemomni.sh
===================================================================
--- trunk/doc/examples/runemomni.sh (rev 0)
+++ trunk/doc/examples/runemomni.sh 2011-07-15 23:20:40 UTC (rev 435)
@@ -0,0 +1,152 @@
+length=30
+confidence="-i 30,3"
+netperf_CPUs="0 1 2"
+netserver_CPUs="0 1 2"
+control_host=192.168.0.26
+remote_hosts="192.168.0.26 fe80::207:43ff:fe05:590a%eth0"
+#reqs="128 256 512 1024"
+reqs="64 128 256 512 1024 1460 2048 4096 8192"
+bursts="0 1 2 4 8 16 32 64 128 256"
+HDR="-P 1"
+# -O means "human" -o means "csv"
+CSV="-o"
+#CSV="-O"
+
+DO_TCP_STREAM_AUTO=1
+DO_TCP_STREAM_SOPT=1
+DO_TCP_BIDIR=1
+DO_TCP_RR=1
+DO_TCP_CC=0
+DO_TCP_BIDIR_REQ=0
+DO_UDP_BIDIR_REQ=0
+DO_UDP_STREAM=1
+
+
+FULL_MATRIX=0
+
+echo interrupts CPU 0 with CPU 1 other socket CPU 2 same socket
+echo ad386a in dl380 g5 2x 5160 at 3GHz to same
+for data in $remote_hosts
+do
+
+ if [ $DO_TCP_STREAM_AUTO -eq 1 ]
+ then
+ echo TCP_STREAM to $data autotuning
+ for i in $netperf_CPUs
+ do
+ if [ $FULL_MATRIX -eq 1 ]
+ then
+ set=$netserver_CPUs
+ else
+ set=$i
+ fi
+ for j in $set
+ do
+ netperf $HDR -T $i,$j -t omni -c -C -H $control_host -l $length $confidence -- $CSV -H $data -m 64K;HDR="-P 0";
+ done
+ done
+ fi
+
+ if [ $DO_TCP_STREAM_SOPT -eq 1 ]
+ then
+ echo TCP_STREAM to $data
+ HDR="-P 1"
+ for i in $netperf_CPUs
+ do
+ if [ $FULL_MATRIX -eq 1 ]
+ then
+ set=$netserver_CPUs
+ else
+ set=$i
+ fi
+ for j in $set
+ do
+ netperf $HDR -T $i,$j -t omni -c -C -H $control_host -l $length $confidence -- $CSV -H $data -s 1M -S 1M -m 64K;HDR="-P 0";
+ done
+ done
+ fi
+
+ if [ $DO_TCP_BIDIR -eq 1 ]
+ then
+ echo bidir TCP_RR MEGABITS to $data
+ HDR="-P 1"
+ for i in $netperf_CPUs
+ do
+ if [ $FULL_MATRIX -eq 1 ]
+ then
+ set=$netserver_CPUs
+ else
+ set=$i
+ fi
+ for j in $set
+ do
+ netperf $HDR -T $i,$j -t omni -f m -c -C -H $control_host -l $length $confidence -- $CSV -H $data -s 1M -S 1M -r 64K -b 12; HDR="-P 0";
+ done
+ done
+ fi
+
+ if [ $DO_TCP_RR -eq 1 ]
+ then
+ echo TCP_RR to $data
+ HDR="-P 1"
+ for i in $netperf_CPUs
+ do
+ if [ $FULL_MATRIX -eq 1 ]
+ then
+ set=$netserver_CPUs
+ else
+ set=$i
+ fi
+ for j in $set
+ do
+ netperf $HDR -T $i,$j -t omni -c -C -H $control_host -l $length $confidence -- $CSV -H $data -r 1; HDR="-P 0";
+ done
+ done
+ fi
+
+ if [ $DO_TCP_BIDIR_REQ -eq 1 ]
+ then
+ echo bidir TCP_RR MEGABITS to $data altering req/rsp size and burst
+ HDR="-P 1"
+ for i in $netperf_CPUs
+ do
+ for req in $reqs; do
+ for burst in $bursts; do
+ netperf $HDR -T $i -t omni -f m -c -C -H $control_host -l $length $confidence -- $CSV -H $data -s 1M -S 1M -r $req -b $burst -D;HDR=-"P 0";
+ done
+ done
+ done
+ fi
+
+ if [ $DO_UDP_BIDIR_REQ -eq 1 ]
+ then
+ echo bidir UDP_RR MEGABITS to $data altering req/rsp size and burst
+ HDR="-P 1"
+ for i in $netperf_CPUs
+ do
+ for req in $reqs; do
+ for burst in $bursts; do
+ netperf $HDR -T $i -t omni -f m -c -C -H $control_host -l $length $confidence -- $CSV -H $data -s 1M -S 1M -r $req -b $burst -T udp;HDR=-"P 0";
+ done
+ done
+ done
+ fi
+
+ if [ $DO_UDP_STREAM -eq 1 ]
+ then
+ echo UDP_STREAM MEGABITS to $data altering send size, no confidence intvls
+ confidence=" "
+ echo CPUs $netperf_CPUs reqs $reqs
+ HDR="-P 1"
+ for i in $netperf_CPUs
+ do
+ for req in $reqs; do
+ netperf $HDR -T $i -t omni -f m -c -C -H $control_host -l $length $confidence -- $CSV -H $data -s 1M -S 1M -m $req -T udp;HDR=-"P 0";
+ done
+ done
+ fi
+
+done
+
+cat /proc/meminfo
+cat /proc/cpuinfo
Added: trunk/doc/examples/runemomniagg2.sh
===================================================================
--- trunk/doc/examples/runemomniagg2.sh (rev 0)
+++ trunk/doc/examples/runemomniagg2.sh 2011-07-15 23:20:40 UTC (rev 435)
@@ -0,0 +1,107 @@
+#set -x
+remote_hosts[0]=192.168.2.3
+remote_hosts[1]=192.168.3.5
+remote_hosts[2]=192.168.4.6
+remote_hosts[3]=192.168.5.7
+remote_hosts[4]=192.168.2.5
+remote_hosts[5]=192.168.3.3
+remote_hosts[6]=192.168.4.7
+remote_hosts[7]=192.168.5.6
+remote_hosts[8]=192.168.2.6
+remote_hosts[9]=192.168.3.7
+remote_hosts[10]=192.168.4.3
+remote_hosts[11]=192.168.5.5
+remote_hosts[12]=192.168.2.7
+remote_hosts[13]=192.168.3.6
+remote_hosts[14]=192.168.4.5
+remote_hosts[15]=192.168.5.3
+num_cli=16
+length=30
+confidence="-i 30,30"
+concurrent_sessions="1 4 8 16 32 64"
+socket_sizes=" -s 1M -S 1M"
+#burst_sizes="0 1 4 16 64 256 1024"
+burst_sizes="0 1 4 16"
+HDR="-P 1"
+# -O means "human" -o means "csv"
+CSV="-o"
+#CSV="-O"
+
+DO_STREAM=
+DO_MAERTS=
+DO_BIDIR=1
+DO_RRAGG=1
+
+#echo "throughput, command_line" > tmpfoo
+#CSV="-o tmpfoo"
+
+echo interrupts spread wherever irqbalanced put them
+echo 4xAD386A in DL785 G5 SLES11B6, HP/vendor drivers
+echo four dl585 G5 clients rh5.2, each with two AD386A
+
+ if [ $DO_STREAM -eq 1 ]; then
+ echo TCP_STREAM
+ for i in $concurrent_sessions; do
+ j=0;
+ NETUUID=`netperf -t uuid`;
+ echo $i concurrent streams id $NETUUID;
+ while [ $j -lt $i ]; do
+ client=`expr $j % $num_cli` ;
+ netperf $HDR -t omni -c -C -H ${remote_hosts[$client]} -l $length $confidence -- $CSV -H ${remote_hosts[$client]} $socket_sizes -m 64K -u $NETUUID & HDR="-P 0";
+ j=`expr $j + 1`;
+ done;
+ wait;
+ done
+ fi
+#
+ if [ $DO_MAERTS -eq 1 ]; then
+ echo TCP_MAERTS
+ for i in $concurrent_sessions; do
+ j=0;
+ NETUUID=`netperf -t uuid`;
+ echo $i concurrent streams id $NETUUID;
+ while [ $j -lt $i ]; do
+ client=`expr $j % $num_cli` ;
+ netperf $HDR -t omni -c -C -H ${remote_hosts[$client]} -l $length $confidence -- $CSV -H ${remote_hosts[$client]} $socket_sizes -M ,64K -u $NETUUID & HDR="-P 0";
+ j=`expr $j + 1`;
+ done;
+ wait;
+ done
+ fi
+
+ if [ $DO_BIDIR -eq 1 ]; then
+ echo bidir TCP_RR MEGABITS
+ HDR="-P 1"
+ for i in $concurrent_sessions;
+ do j=0;
+ NETUUID=`netperf -t uuid`;
+ echo $i concurrent streams id $NETUUID;
+ while [ $j -lt $i ]; do
+ client=`expr $j % $num_cli` ;
+ netperf $HDR -t omni -f m -c -C -H ${remote_hosts[$client]} -l $length $confidence -- $CSV -H ${remote_hosts[$client]} -s 1M -S 1M -r 64K -b 12 -u $NETUUID & HDR="-P 0";
+ j=`expr $j + 1`;
+ done;
+ wait;
+ done
+ fi
+
+ if [ $DO_RRAGG -eq 1 ]; then
+ echo TCP_RR aggregates
+ HDR="-P 1"
+ for i in $concurrent_sessions; do
+ NETUUID=`netperf -t uuid`;
+ echo $i concurrent streams id $NETUUID;
+ for b in $burst_sizes; do
+ echo burst of $b;
+ j=0;
+ while [ $j -lt $i ]; do
+ client=`expr $j % $num_cli` ;
+ netperf $HDR -t omni -f x -c -C -H ${remote_hosts[$client]} -l $length $confidence -- $CSV -H ${remote_hosts[$client]} -r 1 -b $b -D -u $NETUUID & HDR="-P 0";
+ j=`expr $j + 1`;
+ done;
+ wait;
+ done;
+ done
+ fi
+
+cat /proc/meminfo
Modified: trunk/doc/netperf.html
===================================================================
--- trunk/doc/netperf.html 2011-07-15 22:49:13 UTC (rev 434)
+++ trunk/doc/netperf.html 2011-07-15 23:20:40 UTC (rev 435)
@@ -2799,12 +2799,19 @@
</pre>
<p>To have burst-mode functionality present in netperf. This enables a
test-specific <samp><span class="option">-b num</span></samp> option in <a href="#TCP_005fRR">TCP_RR</a>,
-<a href="#UDP_005fRR">UDP_RR</a> and <a href="#The-Omni-Tests">omni</a> tests. This option
-causes those tests to quickly work their way up to having at least
-<samp><span class="option">num</span></samp> plus one transactions in flight at one time.
+<a href="#UDP_005fRR">UDP_RR</a> and <a href="#The-Omni-Tests">omni</a> tests.
- <p>This is used as an alternative to or even in conjunction with
-multiple-concurrent _RR tests and as a way to implement a
+ <p>Normally, netperf will attempt to ramp-up the number of outstanding
+requests to <samp><span class="option">num</span></samp> plus one transactions in flight at one time.
+The ramp-up is to avoid transactions being smashed together into a
+smaller number of segments when the transport's congestion window (if
+any) is smaller at the time than what netperf wants to have
+outstanding at one time. If, however, the user specifies a negative
+value for <samp><span class="option">num</span></samp> this ramp-up is bypassed and the burst of sends
+is made without consideration of transport congestion window.
+
+ <p>This burst-mode is used as an alternative to or even in conjunction
+with multiple-concurrent _RR tests and as a way to implement a
single-connection, bidirectional bulk-transfer test. When run with
just a single instance of netperf, increasing the burst size can
determine the maximum number of transactions per second which can be
@@ -2834,7 +2841,8 @@
set TCP_NODELAY, the stack was free to “bundle” requests and/or
responses into TCP segments as it saw fit, and since the default
request and response size is one byte, there could have been some
-considerable bundling. If one wants to try to achieve a closer to
+considerable bundling even in the absense of transport congestion
+window issues. If one wants to try to achieve a closer to
one-to-one correspondence between a request and response and a TCP
segment, add the test-specific <samp><span class="option">-D</span></samp> option:
Modified: trunk/doc/netperf.info
===================================================================
--- trunk/doc/netperf.info 2011-07-15 22:49:13 UTC (rev 434)
+++ trunk/doc/netperf.info 2011-07-15 23:20:40 UTC (rev 435)
@@ -2443,12 +2443,19 @@
To have burst-mode functionality present in netperf. This enables a
test-specific `-b num' option in *note TCP_RR: TCP_RR, *note UDP_RR:
-UDP_RR. and *note omni: The Omni Tests. tests. This option causes those
-tests to quickly work their way up to having at least `num' plus one
-transactions in flight at one time.
+UDP_RR. and *note omni: The Omni Tests. tests.
- This is used as an alternative to or even in conjunction with
-multiple-concurrent _RR tests and as a way to implement a
+ Normally, netperf will attempt to ramp-up the number of outstanding
+requests to `num' plus one transactions in flight at one time. The
+ramp-up is to avoid transactions being smashed together into a smaller
+number of segments when the transport's congestion window (if any) is
+smaller at the time than what netperf wants to have outstanding at one
+time. If, however, the user specifies a negative value for `num' this
+ramp-up is bypassed and the burst of sends is made without
+consideration of transport congestion window.
+
+ This burst-mode is used as an alternative to or even in conjunction
+with multiple-concurrent _RR tests and as a way to implement a
single-connection, bidirectional bulk-transfer test. When run with
just a single instance of netperf, increasing the burst size can
determine the maximum number of transactions per second which can be
@@ -2477,9 +2484,10 @@
TCP_NODELAY, the stack was free to "bundle" requests and/or responses
into TCP segments as it saw fit, and since the default request and
response size is one byte, there could have been some considerable
-bundling. If one wants to try to achieve a closer to one-to-one
-correspondence between a request and response and a TCP segment, add
-the test-specific `-D' option:
+bundling even in the absense of transport congestion window issues. If
+one wants to try to achieve a closer to one-to-one correspondence
+between a request and response and a TCP segment, add the test-specific
+`-D' option:
for b in 0 1 2 4 8 16 32
do
@@ -4158,22 +4166,22 @@
Node: Running Concurrent Netperf Tests106725
Node: Issues in Running Concurrent Tests110974
Node: Using --enable-burst112483
-Node: Using Netperf to Measure Bidirectional Transfer118886
-Node: Bidirectional Transfer with Concurrent Tests120017
-Node: Bidirectional Transfer with TCP_RR122373
-Node: Implications of Concurrent Tests vs Burst Request/Response124757
-Node: The Omni Tests126570
-Node: Native Omni Tests127617
-Node: Migrated Tests132894
-Node: Omni Output Selection134999
-Node: Omni Output Selectors137980
-Node: Other Netperf Tests165698
-Node: CPU rate calibration166133
-Node: UUID Generation168500
-Node: Address Resolution169215
-Node: Enhancing Netperf171191
-Node: Netperf4172685
-Node: Concept Index173589
-Node: Option Index175915
+Node: Using Netperf to Measure Bidirectional Transfer119352
+Node: Bidirectional Transfer with Concurrent Tests120483
+Node: Bidirectional Transfer with TCP_RR122839
+Node: Implications of Concurrent Tests vs Burst Request/Response125223
+Node: The Omni Tests127036
+Node: Native Omni Tests128083
+Node: Migrated Tests133360
+Node: Omni Output Selection135465
+Node: Omni Output Selectors138446
+Node: Other Netperf Tests166164
+Node: CPU rate calibration166599
+Node: UUID Generation168966
+Node: Address Resolution169681
+Node: Enhancing Netperf171657
+Node: Netperf4173151
+Node: Concept Index174055
+Node: Option Index176381
End Tag Table
Modified: trunk/doc/netperf.pdf
===================================================================
(Binary files differ)
Modified: trunk/doc/netperf.texi
===================================================================
(Binary files differ)
Modified: trunk/doc/netperf.txt
===================================================================
--- trunk/doc/netperf.txt 2011-07-15 22:49:13 UTC (rev 434)
+++ trunk/doc/netperf.txt 2011-07-15 23:20:40 UTC (rev 435)
@@ -2273,12 +2273,19 @@
To have burst-mode functionality present in netperf. This enables a
test-specific `-b num' option in *note TCP_RR: TCP_RR, *note UDP_RR:
-UDP_RR. and *note omni: The Omni Tests. tests. This option causes those
-tests to quickly work their way up to having at least `num' plus one
-transactions in flight at one time.
+UDP_RR. and *note omni: The Omni Tests. tests.
- This is used as an alternative to or even in conjunction with
-multiple-concurrent _RR tests and as a way to implement a
+ Normally, netperf will attempt to ramp-up the number of outstanding
+requests to `num' plus one transactions in flight at one time. The
+ramp-up is to avoid transactions being smashed together into a smaller
+number of segments when the transport's congestion window (if any) is
+smaller at the time than what netperf wants to have outstanding at one
+time. If, however, the user specifies a negative value for `num' this
+ramp-up is bypassed and the burst of sends is made without
+consideration of transport congestion window.
+
+ This burst-mode is used as an alternative to or even in conjunction
+with multiple-concurrent _RR tests and as a way to implement a
single-connection, bidirectional bulk-transfer test. When run with
just a single instance of netperf, increasing the burst size can
determine the maximum number of transactions per second which can be
@@ -2307,9 +2314,10 @@
TCP_NODELAY, the stack was free to "bundle" requests and/or responses
into TCP segments as it saw fit, and since the default request and
response size is one byte, there could have been some considerable
-bundling. If one wants to try to achieve a closer to one-to-one
-correspondence between a request and response and a TCP segment, add
-the test-specific `-D' option:
+bundling even in the absense of transport congestion window issues. If
+one wants to try to achieve a closer to one-to-one correspondence
+between a request and response and a TCP segment, add the test-specific
+`-D' option:
for b in 0 1 2 4 8 16 32
do
@@ -3783,10 +3791,10 @@
-b, Global: See 4.2. (line 706)
-C, Global: See 4.2. (line 726)
-c, Global: See 4.2. (line 717)
--c, Test-specific: See 9.1. (line 2615)
+-c, Test-specific: See 9.1. (line 2623)
-D, Global: See 4.2. (line 740)
-d, Global: See 4.2. (line 731)
--d, Test-specific: See 9.1. (line 2619)
+-d, Test-specific: See 9.1. (line 2627)
-F, Global: See 4.2. (line 760)
-f, Global: See 4.2. (line 751)
-H, Global: See 4.2. (line 779)
@@ -3797,7 +3805,7 @@
-i, Global: See 4.2. (line 863)
-I, Global: See 4.2. (line 814)
-j, Global: See 4.2. (line 889)
--k, Test-specific: See 9.1. (line 2639)
+-k, Test-specific: See 9.1. (line 2647)
-L, Global: See 4.2. (line 947)
-l, Global: See 4.2. (line 926)
-L, Test-specific <1>: See 6.2. (line 1859)
@@ -3808,8 +3816,8 @@
-n, Global: See 4.2. (line 959)
-O, Global: See 4.2. (line 1022)
-o, Global: See 4.2. (line 1013)
--O, Test-specific: See 9.1. (line 2664)
--o, Test-specific: See 9.1. (line 2652)
+-O, Test-specific: See 9.1. (line 2672)
+-o, Test-specific: See 9.1. (line 2660)
-P, Global: See 4.2. (line 1047)
-p, Global: See 4.2. (line 1027)
-P, Test-specific <1>: See 6.2. (line 1866)
@@ -3823,8 +3831,8 @@
-s, Test-specific: See 5.2. (line 1348)
-T, Global: See 4.2. (line 1107)
-t, Global: See 4.2. (line 1075)
--T, Test-specific: See 9.1. (line 2683)
--t, Test-specific: See 9.1. (line 2678)
+-T, Test-specific: See 9.1. (line 2691)
+-t, Test-specific: See 9.1. (line 2686)
-V, Global: See 4.2. (line 1152)
-v, Global: See 4.2. (line 1124)
-W, Global: See 4.2. (line 1164)
More information about the netperf-dev
mailing list