[netperf-dev] netperf2 commit notice r399 - in trunk: . doc src
raj at netperf.org
raj at netperf.org
Fri Jun 24 18:39:17 PDT 2011
Author: raj
Date: 2011-06-24 18:39:16 -0700 (Fri, 24 Jun 2011)
New Revision: 399
Modified:
trunk/Release_Notes
trunk/configure
trunk/configure.ac
trunk/doc/netperf.html
trunk/doc/netperf.info
trunk/doc/netperf.texi
trunk/src/nettest_omni.c
Log:
further doc updates make burst mode for rr tests enabled by default and fix the output of the migrated tcp rr test so it reports the right things when selecting different throughput units
Modified: trunk/Release_Notes
===================================================================
--- trunk/Release_Notes 2011-06-24 23:40:17 UTC (rev 398)
+++ trunk/Release_Notes 2011-06-25 01:39:16 UTC (rev 399)
@@ -1,5 +1,10 @@
These are the Release Notes for post-revision 2.4.5 of netperf:
+*) Base on the frequency at which the author has used the
+ functionality, the default for --enable-burst is yes. To disable
+ support for burst mode one must now include a --enable-burst=no
+ when performing the ./configure prior to compiling the bits.
+
*) The output of the -D global command line option (./configure
--enable-demo) has been enhanced to include seconds and
milliseconds since the epoch as returned by a gettimeofday() call
Modified: trunk/configure
===================================================================
--- trunk/configure 2011-06-24 23:40:17 UTC (rev 398)
+++ trunk/configure 2011-06-25 01:39:16 UTC (rev 399)
@@ -6789,7 +6789,7 @@
use_burst=false
;;
'')
- use_burst=false
+ use_burst=true
;;
*)
as_fn_error $? "--enable-burst takes yes or no" "$LINENO" 5
Modified: trunk/configure.ac
===================================================================
--- trunk/configure.ac 2011-06-24 23:40:17 UTC (rev 398)
+++ trunk/configure.ac 2011-06-25 01:39:16 UTC (rev 399)
@@ -589,7 +589,7 @@
use_burst=false
;;
'')
- use_burst=false
+ use_burst=true
;;
*)
AC_MSG_ERROR([--enable-burst takes yes or no])
Modified: trunk/doc/netperf.html
===================================================================
--- trunk/doc/netperf.html 2011-06-24 23:40:17 UTC (rev 398)
+++ trunk/doc/netperf.html 2011-06-25 01:39:16 UTC (rev 399)
@@ -103,6 +103,7 @@
<ul>
<li><a href="#Bidirectional-Transfer-with-Concurrent-Tests">8.1 Bidirectional Transfer with Concurrent Tests</a>
<li><a href="#Bidirectional-Transfer-with-TCP_005fRR">8.2 Bidirectional Transfer with TCP_RR</a>
+<li><a href="#Implications-of-Concurrent-Tests-vs-Burst-Request_002fResponse">8.3 Implications of Concurrent Tests vs Burst Request/Response</a>
</li></ul>
<li><a name="toc_The-Omni-Tests" href="#The-Omni-Tests">9 The Omni Tests</a>
<ul>
@@ -116,6 +117,7 @@
<li><a name="toc_Other-Netperf-Tests" href="#Other-Netperf-Tests">10 Other Netperf Tests</a>
<ul>
<li><a href="#CPU-rate-calibration">10.1 CPU rate calibration</a>
+<li><a href="#UUID-Generation">10.2 UUID Generation</a>
</li></ul>
<li><a name="toc_Address-Resolution" href="#Address-Resolution">11 Address Resolution</a>
<li><a name="toc_Enhancing-Netperf" href="#Enhancing-Netperf">12 Enhancing Netperf</a>
@@ -2835,6 +2837,7 @@
<ul class="menu">
<li><a accesskey="1" href="#Bidirectional-Transfer-with-Concurrent-Tests">Bidirectional Transfer with Concurrent Tests</a>
<li><a accesskey="2" href="#Bidirectional-Transfer-with-TCP_005fRR">Bidirectional Transfer with TCP_RR</a>
+<li><a accesskey="3" href="#Implications-of-Concurrent-Tests-vs-Burst-Request_002fResponse">Implications of Concurrent Tests vs Burst Request/Response</a>
</ul>
<div class="node">
@@ -2868,7 +2871,6 @@
892.66 outbound
891.34 inbound
-
</pre>
<p>We have used a <code>for</code> loop in the shell with just one iteration
because that will be <b>much</b> easier to get both tests started at more or
@@ -2880,10 +2882,23 @@
that sense is switched on the system running netserver :) The use of
the global <samp><span class="option">-i</span></samp> option is explained in <a href="#Running-Concurrent-Netperf-Tests">Running Concurrent Netperf Tests</a>.
-<div class="node">
+ <p>Beginning with version 2.5.0 we can accomplish a similar result with
+the <a href="#The-Omni-Tests">the omni tests</a> and <a href="#Omni-Output-Selectors">output selectors</a>:
+
+<pre class="example"> for i in 1
+ do
+ netperf -H 192.168.1.3 -t omni -l 10 -P 0 -- -d stream -s 256K -S 256K -o throughput,direction &
+ netperf -H 192.168.1.3 -t omni -l 10 -P 0 -- -d maerts -s 256K -S 256K -o throughput,direction &
+ done
+
+ 805.26,Receive
+ 828.54,Send
+</pre>
+ <div class="node">
<a name="Bidirectional-Transfer-with-TCP_RR"></a>
<a name="Bidirectional-Transfer-with-TCP_005fRR"></a>
<p><hr>
+Next: <a rel="next" accesskey="n" href="#Implications-of-Concurrent-Tests-vs-Burst-Request_002fResponse">Implications of Concurrent Tests vs Burst Request/Response</a>,
Previous: <a rel="previous" accesskey="p" href="#Bidirectional-Transfer-with-Concurrent-Tests">Bidirectional Transfer with Concurrent Tests</a>,
Up: <a rel="up" accesskey="u" href="#Using-Netperf-to-Measure-Bidirectional-Transfer">Using Netperf to Measure Bidirectional Transfer</a>
@@ -2892,52 +2907,89 @@
<!-- node-name, next, previous, up -->
<h3 class="section">8.2 Bidirectional Transfer with TCP_RR</h3>
-<p>If one configures netperf with <code>--enable-burst</code> then one can use
-the test-specific <samp><span class="option">-b</span></samp> option to increase the number of
-transactions in flight at one time. If one also uses the -r option to
-make those transactions larger the test starts to look more and more
-like a bidirectional transfer than a request/response test.
+<p>Starting with version 2.5.0 the <code>--enable-burst</code> configure option
+defaults to <code>yes</code>, and starting some time before version 2.5.0
+but after 2.4.0 the global <samp><span class="option">-f</span></samp> option would affect the
+“throughput” reported by request/response tests. If one uses the
+test-specific <samp><span class="option">-b</span></samp> option to have several “transactions” in
+flight at one time and the test-specific <samp><span class="option">-r</span></samp> option to
+increase their size, the test looks more and more like a
+single-connection bidirectional transfer than a simple
+request/response test.
- <p>Now, the logic behing <code>--enable-burst</code> is very simple, and there
-are no calls to <code>poll()</code> or <code>select()</code> which means we want
-to make sure that the <code>send()</code> calls will never block, or we run
-the risk of deadlock with each side stuck trying to call <code>send()</code>
-and neither calling <code>recv()</code>.
+ <p>So, putting it all together one can do something like:
+<pre class="example"> netperf -f m -t TCP_RR -H 192.168.1.3 -v 2 -- -b 6 -r 32K -S 256K -S 256K
+ MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.1.3 (192.168.1.3) port 0 AF_INET : interval : first burst 6
+ Local /Remote
+ Socket Size Request Resp. Elapsed
+ Send Recv Size Size Time Throughput
+ bytes Bytes bytes bytes secs. 10^6bits/sec
+
+ 16384 87380 32768 32768 10.00 1821.30
+ 524288 524288
+ Alignment Offset RoundTrip Trans Throughput
+ Local Remote Local Remote Latency Rate 10^6bits/s
+ Send Recv Send Recv usec/Tran per sec Outbound Inbound
+ 8 0 0 0 2015.402 3473.252 910.492 910.492
+</pre>
+ <p>to get a bidirectional bulk-throughput result. As one can see, the -v
+2 output will include a number of interesting, related values.
+
+ <blockquote>
+<b>NOTE: The logic behind </b><code>--enable-burst</code><b> is very simple, and there
+are no calls to </b><code>poll()</code><b> or </b><code>select()</code><b> which means we want
+to make sure that the </b><code>send()</code><b> calls will never block, or we run
+the risk of deadlock with each side stuck trying to call </b><code>send()</code><b>
+and neither calling </b><code>recv()</code><b>.</b>
+</blockquote>
+
<p>Fortunately, this is easily accomplished by setting a “large enough”
socket buffer size with the test-specific <samp><span class="option">-s</span></samp> and <samp><span class="option">-S</span></samp>
options. Presently this must be performed by the user. Future
versions of netperf might attempt to do this automagically, but there
are some issues to be worked-out.
- <p>Here then is an example of a bidirectional transfer test using
-<code>--enable-burst</code> and the <a href="#TCP_005fRR">TCP_RR</a> test:
+<div class="node">
+<a name="Implications-of-Concurrent-Tests-vs-Burst-Request%2fResponse"></a>
+<a name="Implications-of-Concurrent-Tests-vs-Burst-Request_002fResponse"></a>
+<p><hr>
+Previous: <a rel="previous" accesskey="p" href="#Bidirectional-Transfer-with-TCP_005fRR">Bidirectional Transfer with TCP_RR</a>,
+Up: <a rel="up" accesskey="u" href="#Using-Netperf-to-Measure-Bidirectional-Transfer">Using Netperf to Measure Bidirectional Transfer</a>
-<pre class="example"> netperf -t TCP_RR -H hpcpc108 -- -b 6 -r 32K -s 256K -S 256K
- TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to hpcpc108.cup.hp.com (16.89.84.108) port 0 AF_INET : first burst 6
- Local /Remote
- Socket Size Request Resp. Elapsed Trans.
- Send Recv Size Size Time Rate
- bytes Bytes bytes bytes secs. per sec
-
- 524288 524288 32768 32768 10.01 3525.97
- 524288 524288
-
-</pre>
- <p>Now, at present netperf does not include a bit or byte rate in the
-output of an _RR test which means we must calculate it ourselves. Each
-transaction is the exchange of 32768 bytes of request and 32768 bytes
-of response, or 65536 bytes. Multiply that by 8 and we arrive at
-524288 bits per transaction. Multiply that by 3525.97 and we arrive
-at 1848623759 bits per second. Since things were uniform, we can
-divide that by two and arrive at roughly 924311879 bits per second
-each way. That corresponds to “link-rate” for a 1 Gigiabit Ethernet
-which happens to be the type of netpwrk used in the example.
+</div>
- <p>A future version of netperf may perform the calculation on behalf of
-the user, but it would likely not emit it unless the user specified a
-verbosity of 2 or more with the global <samp><span class="option">-v</span></samp> option.
+<h3 class="section">8.3 Implications of Concurrent Tests vs Burst Request/Response</h3>
+<p>There are perhaps subtle but important differences between using
+concurrent unidirectional tests vs a burst-mode request to measure
+bidirectional performance.
+
+ <p>Broadly speaking, a single “connection” or “flow” of traffic
+cannot make use of the services of more than one or two CPUs at either
+end. Whether one or two CPUs will be used processing a flow will
+depend on the specifics of the stack(s) involved and whether or not
+the global <samp><span class="option">-T</span></samp> option has been used to bind netperf/netserver
+to specific CPUs.
+
+ <p>When using concurrent tests there will be two concurrent connections
+or flows, which means that upwards of four CPUs will be employed
+processing the packets, however, with just a single, bidirectional
+request/response test no more than two CPUs will be employed.
+
+ <p>If there is a CPU bottleneck on either system this may result in
+rather different results between the two methods.
+
+ <p>Also, with a bidirectional request/response test there is something of
+a natural balance or synchronization between inbound and outbound - a
+response will not be sent until a request is received, and (once the
+burst level is reached) a subseqent request will not be sent until a
+response is received. This may mask favoritism in the NIC between
+inbound and outbound processing.
+
+ <p>With two concurrent unidirectional tests there is no such
+synchronization or balance and any favoritism in the NIC may be exposed.
+
<div class="node">
<a name="The-Omni-Tests"></a>
<p><hr>
@@ -2996,15 +3048,21 @@
establishment and tear-down as in either a TCP_CRR or TCP_CC test.
<p><a name="index-g_t_002dd_002c-Test_002dspecific-85"></a><br><dt><code>-d <direction></code><dd>This option sets the direction of the test relative to the netperf
-process. As of version 2.5.0 one can use:
+process. As of version 2.5.0 one can use the following in a
+case-insenstive manner:
<dl>
-<dt><code>send, xmit or 2</code><dd>Any of which will cause netperf to send to the netserver.
-<br><dt><code>recv, receive or 4</code><dd>Any of which will cause netserver to send to netperf.
+<dt><code>send, stream, transmit, xmit or 2</code><dd>Any of which will cause netperf to send to the netserver.
+<br><dt><code>recv, receive, maerts or 4</code><dd>Any of which will cause netserver to send to netperf.
<br><dt><code>rr or 6</code><dd>Either of which will cause a request/response test.
</dl>
- <p><a name="index-g_t_002dk_002c-Test_002dspecific-86"></a><br><dt><code>-k <output selector></code><dd>This option sets the style of output to “keyval” where each line of
+ <p>Additionally, one can specify two directions separated by a '|'
+character and they will be OR'ed together. In this way one can use
+the ”Send|Recv” that will be emitted by the <a href="#Omni-Output-Selectors">DIRECTION</a> <a href="#Omni-Output-Selection">output selector</a> when
+used with a request/reponse test.
+
+ <p><a name="index-g_t_002dk_002c-Test_002dspecific-86"></a><br><dt><code>-k <<a href="#Omni-Output-Selection">output selector</a>></code><dd>This option sets the style of output to “keyval” where each line of
output has the form:
<pre class="example"> key=value
</pre>
@@ -3017,7 +3075,7 @@
<p>Using the <samp><span class="option">-k</span></samp> option will override any previous, test-specific
<samp><span class="option">-o</span></samp> or <samp><span class="option">-O</span></samp> option.
- <p><a name="index-g_t_002do_002c-Test_002dspecific-87"></a><br><dt><code>-o <output selector></code><dd>This option sets the style of output to “CSV” where there will be
+ <p><a name="index-g_t_002do_002c-Test_002dspecific-87"></a><br><dt><code>-o <<a href="#Omni-Output-Selection">output selector</a>></code><dd>This option sets the style of output to “CSV” where there will be
one line of comma-separated values, preceeded by one line of column
names unless the global <samp><span class="option">-P</span></samp> option is used with a value of 0:
<pre class="example"> $ netperf -t omni -- -d rr -o "THROUGHPUT,THROUGHPUT_UNITS"
@@ -3028,7 +3086,7 @@
<p>Using the <samp><span class="option">-o</span></samp> option will override any previous, test-specific
<samp><span class="option">-k</span></samp> or <samp><span class="option">-O</span></samp> option.
- <p><a name="index-g_t_002dO_002c-Test_002dspecific-88"></a><br><dt><code>-O <output selector></code><dd>This option sets the style of output to “human readable” which will
+ <p><a name="index-g_t_002dO_002c-Test_002dspecific-88"></a><br><dt><code>-O <<a href="#Omni-Output-Selection">output selector</a>></code><dd>This option sets the style of output to “human readable” which will
look quite similar to classic netperf output:
<pre class="example"> $ netperf -t omni -- -d rr -O "THROUGHPUT,THROUGHPUT_UNITS"
OMNI TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to localhost.localdomain (127.0.0.1) port 0 AF_INET : demo
@@ -3041,8 +3099,22 @@
<p>Using the <samp><span class="option">-O</span></samp> option will override any previous, test-specific
<samp><span class="option">-k</span></samp> or <samp><span class="option">-o</span></samp> option.
- <p><a name="index-g_t_002dT_002c-Test_002dspecific-89"></a><br><dt><code>-T <protocol></code><dd>This option is used to explicitly set the protocol used for the test.
+ <p><a name="index-g_t_002dt_002c-Test_002dspecific-89"></a><br><dt><code>-t</code><dd>This option explicitly sets the socket type for the test's data
+connection. As of version 2.5.0 the known socket types include
+“stream” and “dgram” for SOCK_STREAM and SOCK_DGRAM respectively.
+ <p><a name="index-g_t_002dT_002c-Test_002dspecific-90"></a><br><dt><code>-T <protocol></code><dd>This option is used to explicitly set the protocol used for the
+test. It is case-insensitive. As of version 2.5.0 the protocols known
+to netperf include:
+ <dl>
+<dt><code>TCP</code><dd>Select the Transmission Control Protocol
+<br><dt><code>UDP</code><dd>Select the User Datagram Procotol
+<br><dt><code>SDP</code><dd>Select the Sockets Direct Protocol
+<br><dt><code>DCCP</code><dd>Select the Datagram Congestion Control Protocol
+<br><dt><code>SCTP</code><dd>Select the Stream Control Transport Protocol
+<br><dt><code>udplite</code><dd>Select UDP Lite
+</dl>
+
<p>The default is implicit based on other settings.
</dl>
@@ -3577,11 +3649,13 @@
<ul class="menu">
<li><a accesskey="1" href="#CPU-rate-calibration">CPU rate calibration</a>
+<li><a accesskey="2" href="#UUID-Generation">UUID Generation</a>
</ul>
<div class="node">
<a name="CPU-rate-calibration"></a>
<p><hr>
+Next: <a rel="next" accesskey="n" href="#UUID-Generation">UUID Generation</a>,
Previous: <a rel="previous" accesskey="p" href="#Other-Netperf-Tests">Other Netperf Tests</a>,
Up: <a rel="up" accesskey="u" href="#Other-Netperf-Tests">Other Netperf Tests</a>
@@ -3631,6 +3705,29 @@
calculate service demands by hand.
<div class="node">
+<a name="UUID-Generation"></a>
+<p><hr>
+Previous: <a rel="previous" accesskey="p" href="#CPU-rate-calibration">CPU rate calibration</a>,
+Up: <a rel="up" accesskey="u" href="#Other-Netperf-Tests">Other Netperf Tests</a>
+
+</div>
+
+<h3 class="section">10.2 UUID Generation</h3>
+
+<p>Beginning with version 2.5.0 netperf can generate Universally Unique
+IDentifiers (UUIDs). This can be done explicitly via the “UUID”
+test:
+<pre class="example"> $ netperf -t UUID
+ 2c8561ae-9ebd-11e0-a297-0f5bfa0349d0
+</pre>
+ <p>In and of itself, this is not terribly useful, but used in conjuction
+with the test-specific <samp><span class="option">-u</span></samp> option of an “omni” test to set
+the UUID emitted by the <a href="#Omni-Output-Selectors">UUID</a> output
+selector, it can be used to tie-together the separate instances of an
+aggregate netperf test. Say, for instance if they were inserted into
+a database of some sort.
+
+<div class="node">
<a name="Address-Resolution"></a>
<p><hr>
Next: <a rel="next" accesskey="n" href="#Enhancing-Netperf">Enhancing Netperf</a>,
@@ -3856,7 +3953,8 @@
<li><a href="#index-g_t_002ds_002c-Test_002dspecific-60"><code>-s, Test-specific</code></a>: <a href="#Options-Common-to-TCP-UDP-and-SCTP-_005fRR-tests">Options Common to TCP UDP and SCTP _RR tests</a></li>
<li><a href="#index-g_t_002ds_002c-Test_002dspecific-50"><code>-s, Test-specific</code></a>: <a href="#Options-common-to-TCP-UDP-and-SCTP-tests">Options common to TCP UDP and SCTP tests</a></li>
<li><a href="#index-g_t_002dt_002c-Global-38"><code>-t, Global</code></a>: <a href="#Global-Options">Global Options</a></li>
-<li><a href="#index-g_t_002dT_002c-Test_002dspecific-89"><code>-T, Test-specific</code></a>: <a href="#Native-Omni-Tests">Native Omni Tests</a></li>
+<li><a href="#index-g_t_002dT_002c-Test_002dspecific-90"><code>-T, Test-specific</code></a>: <a href="#Native-Omni-Tests">Native Omni Tests</a></li>
+<li><a href="#index-g_t_002dt_002c-Test_002dspecific-89"><code>-t, Test-specific</code></a>: <a href="#Native-Omni-Tests">Native Omni Tests</a></li>
<li><a href="#index-g_t_002dV_002c-Global-40"><code>-V, Global</code></a>: <a href="#Global-Options">Global Options</a></li>
<li><a href="#index-g_t_002dv_002c-Global-39"><code>-v, Global</code></a>: <a href="#Global-Options">Global Options</a></li>
<li><a href="#index-g_t_002dW_002c-Global-42"><code>-W, Global</code></a>: <a href="#Global-Options">Global Options</a></li>
Modified: trunk/doc/netperf.info
===================================================================
--- trunk/doc/netperf.info 2011-06-24 23:40:17 UTC (rev 398)
+++ trunk/doc/netperf.info 2011-06-25 01:39:16 UTC (rev 399)
@@ -2515,6 +2515,19 @@
explained in *note Running Concurrent Netperf Tests: Running Concurrent
Netperf Tests.
+ Beginning with version 2.5.0 we can accomplish a similar result with
+the *note the omni tests: The Omni Tests. and *note output selectors:
+Omni Output Selectors.:
+
+ for i in 1
+ do
+ netperf -H 192.168.1.3 -t omni -l 10 -P 0 -- -d stream -s 256K -S 256K -o throughput,direction &
+ netperf -H 192.168.1.3 -t omni -l 10 -P 0 -- -d maerts -s 256K -S 256K -o throughput,direction &
+ done
+
+ 805.26,Receive
+ 828.54,Send
+
File: netperf.info, Node: Bidirectional Transfer with TCP_RR, Prev: Bidirectional Transfer with Concurrent Tests, Up: Using Netperf to Measure Bidirectional Transfer
@@ -2614,18 +2627,25 @@
`-d <direction>'
This option sets the direction of the test relative to the netperf
- process. As of version 2.5.0 one can use:
+ process. As of version 2.5.0 one can use the following in a
+ case-insenstive manner:
- `send, xmit or 2'
+ `send, stream, transmit, xmit or 2'
Any of which will cause netperf to send to the netserver.
- `recv, receive or 4'
+ `recv, receive, maerts or 4'
Any of which will cause netserver to send to netperf.
`rr or 6'
Either of which will cause a request/response test.
-`-k <output selector>'
+ Additionally, one can specify two directions separated by a '|'
+ character and they will be OR'ed together. In this way one can use
+ the "Send|Recv" that will be emitted by the *note DIRECTION: Omni
+ Output Selectors. *note output selector: Omni Output Selection.
+ when used with a request/reponse test.
+
+`-k <*note output selector: Omni Output Selection.>'
This option sets the style of output to "keyval" where each line of
output has the form:
key=value
@@ -2638,7 +2658,7 @@
Using the `-k' option will override any previous, test-specific
`-o' or `-O' option.
-`-o <output selector>'
+`-o <*note output selector: Omni Output Selection.>'
This option sets the style of output to "CSV" where there will be
one line of comma-separated values, preceeded by one line of column
names unless the global `-P' option is used with a value of 0:
@@ -2650,7 +2670,7 @@
Using the `-o' option will override any previous, test-specific
`-k' or `-O' option.
-`-O <output selector>'
+`-O <*note output selector: Omni Output Selection.>'
This option sets the style of output to "human readable" which will
look quite similar to classic netperf output:
$ netperf -t omni -- -d rr -O "THROUGHPUT,THROUGHPUT_UNITS"
@@ -2664,10 +2684,33 @@
Using the `-O' option will override any previous, test-specific
`-k' or `-o' option.
+`-t'
+ This option explicitly sets the socket type for the test's data
+ connection. As of version 2.5.0 the known socket types include
+ "stream" and "dgram" for SOCK_STREAM and SOCK_DGRAM respectively.
+
`-T <protocol>'
This option is used to explicitly set the protocol used for the
- test.
+ test. It is case-insensitive. As of version 2.5.0 the protocols
+ known to netperf include:
+ `TCP'
+ Select the Transmission Control Protocol
+ `UDP'
+ Select the User Datagram Procotol
+
+ `SDP'
+ Select the Sockets Direct Protocol
+
+ `DCCP'
+ Select the Datagram Congestion Control Protocol
+
+ `SCTP'
+ Select the Stream Control Transport Protocol
+
+ `udplite'
+ Select UDP Lite
+
The default is implicit based on other settings.
@@ -3524,9 +3567,10 @@
* Menu:
* CPU rate calibration::
+* UUID Generation::
-File: netperf.info, Node: CPU rate calibration, Prev: Other Netperf Tests, Up: Other Netperf Tests
+File: netperf.info, Node: CPU rate calibration, Next: UUID Generation, Prev: Other Netperf Tests, Up: Other Netperf Tests
10.1 CPU rate calibration
=========================
@@ -3572,6 +3616,24 @@
by hand.
+File: netperf.info, Node: UUID Generation, Prev: CPU rate calibration, Up: Other Netperf Tests
+
+10.2 UUID Generation
+====================
+
+Beginning with version 2.5.0 netperf can generate Universally Unique
+IDentifiers (UUIDs). This can be done explicitly via the "UUID" test:
+ $ netperf -t UUID
+ 2c8561ae-9ebd-11e0-a297-0f5bfa0349d0
+
+ In and of itself, this is not terribly useful, but used in conjuction
+with the test-specific `-u' option of an "omni" test to set the UUID
+emitted by the *note UUID: Omni Output Selectors. output selector, it
+can be used to tie-together the separate instances of an aggregate
+netperf test. Say, for instance if they were inserted into a database
+of some sort.
+
+
File: netperf.info, Node: Address Resolution, Next: Enhancing Netperf, Prev: Other Netperf Tests, Up: Top
11 Address Resolution
@@ -3766,7 +3828,7 @@
* -i, Global: Global Options. (line 178)
* -I, Global: Global Options. (line 129)
* -j, Global: Global Options. (line 199)
-* -k, Test-specific: Native Omni Tests. (line 30)
+* -k, Test-specific: Native Omni Tests. (line 37)
* -L, Global: Global Options. (line 241)
* -l, Global: Global Options. (line 221)
* -L, Test-specific <1>: Options Common to TCP UDP and SCTP _RR tests.
@@ -3781,8 +3843,8 @@
* -n, Global: Global Options. (line 253)
* -O, Global: Global Options. (line 316)
* -o, Global: Global Options. (line 307)
-* -O, Test-specific: Native Omni Tests. (line 55)
-* -o, Test-specific: Native Omni Tests. (line 43)
+* -O, Test-specific: Native Omni Tests. (line 62)
+* -o, Test-specific: Native Omni Tests. (line 50)
* -P, Global: Global Options. (line 340)
* -p, Global: Global Options. (line 320)
* -P, Test-specific <1>: Options Common to TCP UDP and SCTP _RR tests.
@@ -3800,7 +3862,8 @@
* -s, Test-specific: Options common to TCP UDP and SCTP tests.
(line 64)
* -t, Global: Global Options. (line 349)
-* -T, Test-specific: Native Omni Tests. (line 69)
+* -T, Test-specific: Native Omni Tests. (line 81)
+* -t, Test-specific: Native Omni Tests. (line 76)
* -V, Global: Global Options. (line 403)
* -v, Global: Global Options. (line 381)
* -W, Global: Global Options. (line 415)
@@ -3855,18 +3918,19 @@
Node: Using --enable-burst103932
Node: Using Netperf to Measure Bidirectional Transfer110118
Node: Bidirectional Transfer with Concurrent Tests111186
-Node: Bidirectional Transfer with TCP_RR113052
-Node: The Omni Tests115586
-Node: Native Omni Tests116633
-Node: Migrated Tests119484
-Node: Omni Output Selection121589
-Node: Omni Output Selectors123888
-Node: Other Netperf Tests151515
-Node: CPU rate calibration151930
-Node: Address Resolution154273
-Node: Enhancing Netperf156249
-Node: Netperf4157678
-Node: Concept Index158588
-Node: Option Index160914
+Node: Bidirectional Transfer with TCP_RR113500
+Node: The Omni Tests116034
+Node: Native Omni Tests117081
+Node: Migrated Tests121075
+Node: Omni Output Selection123180
+Node: Omni Output Selectors125479
+Node: Other Netperf Tests153106
+Node: CPU rate calibration153541
+Node: UUID Generation155908
+Node: Address Resolution156623
+Node: Enhancing Netperf158599
+Node: Netperf4160028
+Node: Concept Index160938
+Node: Option Index163264
End Tag Table
Modified: trunk/doc/netperf.texi
===================================================================
(Binary files differ)
Modified: trunk/src/nettest_omni.c
===================================================================
--- trunk/src/nettest_omni.c 2011-06-24 23:40:17 UTC (rev 398)
+++ trunk/src/nettest_omni.c 2011-06-25 01:39:16 UTC (rev 399)
@@ -7003,9 +7003,7 @@
calc_thruput_interval_omni with an elapsed time of
1.0 s to get it converted to [kmg]bits/s or
[KMG]Bytes/s */
- ('x' == libfmt) ? thruput :
- calc_thruput_interval_omni(thruput * (req_size+rsp_size),
- 1.0),
+ thruput,
((print_headers) ||
(result_brand == NULL)) ? "" : result_brand);
fprintf(where,
@@ -7054,11 +7052,13 @@
outstanding at any one time. otherwise we will
underreport the latency of individual
transactions. learned from saf by raj 2007-06-08 */
- (((double)1.0/thruput)*(double)1000000.0) *
+ (((double)1.0/transaction_rate)*(double)1000000.0) *
(double) (1 + ((first_burst_size > 0) ? first_burst_size : 0)),
- thruput,
- calc_thruput_interval_omni(thruput * (double)req_size,1.0),
- calc_thruput_interval_omni(thruput * (double)rsp_size,1.0));
+ transaction_rate,
+ calc_thruput_interval_omni(transaction_rate * (double)req_size,
+ 1.0),
+ calc_thruput_interval_omni(transaction_rate * (double)rsp_size,
+ 1.0));
#ifdef WANT_HISTOGRAM
fprintf(where,"\nHistogram of request/response times\n");
More information about the netperf-dev
mailing list