[netperf-dev] netperf4 commit notice r5 - in trunk: doc src
raj at netperf.org
raj at netperf.org
Tue Oct 25 15:01:25 PDT 2005
Author: raj
Date: 2005-10-25 15:01:20 -0700 (Tue, 25 Oct 2005)
New Revision: 5
Modified:
trunk/doc/netperf4.html
trunk/doc/netperf4.pdf
trunk/doc/netperf4.ps
trunk/doc/netperf4.xml
trunk/src/Makefile.am
trunk/src/Makefile.in
trunk/src/netlib.c
trunk/src/netperf.h
Log:
Have some of the include files "installed" so folks wanting to write their
own tests can find them in a common place, and do a bit of namespace work.
Modified: trunk/doc/netperf4.html
===================================================================
--- trunk/doc/netperf4.html 2005-10-25 21:31:11 UTC (rev 4)
+++ trunk/doc/netperf4.html 2005-10-25 22:01:20 UTC (rev 5)
@@ -3,7 +3,7 @@
<title>Care and Feeding of Netperf 4.X.X</title>
<meta http-equiv="Content-Type" content="text/html">
<meta name="description" content="Care and Feeding of Netperf 4.X.X">
-<meta name="generator" content="makeinfo 4.7">
+<meta name="generator" content="makeinfo 4.8">
<link title="Top" rel="top" href="#Top">
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
<!--
@@ -25,8 +25,9 @@
pre.smallformat { font-family:inherit; font-size:smaller }
pre.smallexample { font-size:smaller }
pre.smalllisp { font-size:smaller }
- span.sc { font-variant:small-caps }
- span.roman { font-family: serif; font-weight: normal; }
+ span.sc { font-variant:small-caps }
+ span.roman { font-family:serif; font-weight:normal; }
+ span.sansserif { font-family:sans-serif; font-weight:normal; }
--></style>
</head>
<body>
@@ -104,10 +105,11 @@
<div class="node">
<p><hr>
-<a name="Top"></a>Next: <a rel="next" accesskey="n" href="#Introduction">Introduction</a>,
+<a name="Top"></a>
+Next: <a rel="next" accesskey="n" href="#Introduction">Introduction</a>,
Previous: <a rel="previous" accesskey="p" href="#dir">(dir)</a>,
Up: <a rel="up" accesskey="u" href="#dir">(dir)</a>
-<br>
+
</div>
<h2 class="unnumbered">Netperf Manual</h2>
@@ -119,7 +121,7 @@
<blockquote>
Permission is granted to copy, distribute and/or modify this document
per the terms of the netperf4 source licence, a copy of which can be
-found in the file <span class="file">COPYING</span> of the basic netperf4 distribution.
+found in the file <samp><span class="file">COPYING</span></samp> of the basic netperf4 distribution.
</blockquote>
<ul class="menu">
@@ -139,10 +141,11 @@
<div class="node">
<p><hr>
-<a name="Introduction"></a>Next: <a rel="next" accesskey="n" href="#Installing-Netperf">Installing Netperf</a>,
+<a name="Introduction"></a>
+Next: <a rel="next" accesskey="n" href="#Installing-Netperf">Installing Netperf</a>,
Previous: <a rel="previous" accesskey="p" href="#Top">Top</a>,
Up: <a rel="up" accesskey="u" href="#Top">Top</a>
-<br>
+
</div>
<h2 class="chapter">1 Introduction</h2>
@@ -202,9 +205,10 @@
<div class="node">
<p><hr>
-<a name="Conventions"></a>Previous: <a rel="previous" accesskey="p" href="#Introduction">Introduction</a>,
+<a name="Conventions"></a>
+Previous: <a rel="previous" accesskey="p" href="#Introduction">Introduction</a>,
Up: <a rel="up" accesskey="u" href="#Introduction">Introduction</a>
-<br>
+
</div>
<h3 class="section">1.1 Conventions</h3>
@@ -246,7 +250,7 @@
<p>Netperf has two types of command-line options. The first are global
command line options. They are essentially any option not tied to a
particular test or group of tests. An example of a global
-command-line option is the one which sets the test type - <span class="option">-t</span>.
+command-line option is the one which sets the test type - <samp><span class="option">-t</span></samp>.
<p>The second type of options are test-specific options. These are
options which are only applicable to a particular test or set of
@@ -260,10 +264,11 @@
</pre>
<div class="node">
<p><hr>
-<a name="Installing-Netperf"></a>Next: <a rel="next" accesskey="n" href="#The-Design-of-Netperf">The Design of Netperf</a>,
+<a name="Installing-Netperf"></a>
+Next: <a rel="next" accesskey="n" href="#The-Design-of-Netperf">The Design of Netperf</a>,
Previous: <a rel="previous" accesskey="p" href="#Introduction">Introduction</a>,
Up: <a rel="up" accesskey="u" href="#Top">Top</a>
-<br>
+
</div>
<h2 class="chapter">2 Installing Netperf</h2>
@@ -275,12 +280,12 @@
styles of netperf installation. The first runs the netperf server
program - netserver - as a child of inetd. This requires the
installer to have sufficient privileges to edit the files
-<span class="file">/etc/services</span> and <span class="file">/etc/inetd.conf</span> or their
+<samp><span class="file">/etc/services</span></samp> and <samp><span class="file">/etc/inetd.conf</span></samp> or their
platform-specific equivalents.
<p>The second style is to run netserver as a standalone daemon. This
-second method does not require edit privileges on <span class="file">/etc/services</span>
-and <span class="file">/etc/inetd.conf</span> but does mean you must remember to run the
+second method does not require edit privileges on <samp><span class="file">/etc/services</span></samp>
+and <samp><span class="file">/etc/inetd.conf</span></samp> but does mean you must remember to run the
netserver program explicitly after every system reboot.
<p>This manual assumes that those wishing to measure networking
@@ -301,10 +306,11 @@
<div class="node">
<p><hr>
-<a name="Getting-Netperf-Bits"></a>Next: <a rel="next" accesskey="n" href="#Installing-Netperf-Bits">Installing Netperf Bits</a>,
+<a name="Getting-Netperf-Bits"></a>
+Next: <a rel="next" accesskey="n" href="#Installing-Netperf-Bits">Installing Netperf Bits</a>,
Previous: <a rel="previous" accesskey="p" href="#Installing-Netperf">Installing Netperf</a>,
Up: <a rel="up" accesskey="u" href="#Installing-Netperf">Installing Netperf</a>
-<br>
+
</div>
<h3 class="section">2.1 Getting Netperf Bits</h3>
@@ -335,10 +341,11 @@
<div class="node">
<p><hr>
-<a name="Installing-Netperf-Bits"></a>Next: <a rel="next" accesskey="n" href="#Verifying-Installation">Verifying Installation</a>,
+<a name="Installing-Netperf-Bits"></a>
+Next: <a rel="next" accesskey="n" href="#Verifying-Installation">Verifying Installation</a>,
Previous: <a rel="previous" accesskey="p" href="#Getting-Netperf-Bits">Getting Netperf Bits</a>,
Up: <a rel="up" accesskey="u" href="#Installing-Netperf">Installing Netperf</a>
-<br>
+
</div>
<h3 class="section">2.2 Installing Netperf</h3>
@@ -375,7 +382,7 @@
<p>On some platforms, it may be necessary to precede the configure
command with a CFLAGS and/or LIBS variable as the netperf configure
script is not yet smart enough to set them itself. Whenever possible,
-these requirements will be found in <span class="file">README.</span><var>platform</var> files.
+these requirements will be found in <samp><span class="file">README.</span><var>platform</var></samp> files.
Expertise and assistance in making that more automagical in the
configure script would be most welcome.
@@ -422,10 +429,10 @@
hundred to one-hundred, ninety-nine microseconds, but they were
occasionally as long as ten to nineteen milliseconds
- <p>The <span class="option">--enable-demo=yes</span> configure option will cause code to be
+ <p>The <samp><span class="option">--enable-demo=yes</span></samp> configure option will cause code to be
included to report interim results during a test run. The rate at
which interim results are reported can then be controlled via the
-global <span class="option">-D</span> option. Here is an example of –enable-demo mode
+global <samp><span class="option">-D</span></samp> option. Here is an example of –enable-demo mode
output:
<pre class="example"> src/netperf -D 1.35 -H lag -f M
@@ -445,14 +452,14 @@
32768 16384 16384 10.00 9.61
</pre>
<p>Notice how the units of the interim result track that requested by the
-<span class="option">-f</span> option. Also notice that sometimes the interval will be
-longer than the value specified in the <span class="option">-D</span> option. This is
+<samp><span class="option">-f</span></samp> option. Also notice that sometimes the interval will be
+longer than the value specified in the <samp><span class="option">-D</span></samp> option. This is
normal and stems from how demo mode is implemented without relying on
interval timers, but by calculating how many units of work must be
performed to take at least the desired interval.
<p>As of this writing, a <code>make install</code> will not actually update the
-files <span class="file">/etc/services</span> and/or <span class="file">/etc/inetd.conf</span> or their
+files <samp><span class="file">/etc/services</span></samp> and/or <samp><span class="file">/etc/inetd.conf</span></samp> or their
platform-specific equivalents. It remains necessary to perform that
bit of installation magic by hand. Patches to the makefile sources to
effect an automagic editing of the necessary files to have netperf
@@ -475,9 +482,10 @@
<div class="node">
<p><hr>
-<a name="Verifying-Installation"></a>Previous: <a rel="previous" accesskey="p" href="#Installing-Netperf-Bits">Installing Netperf Bits</a>,
+<a name="Verifying-Installation"></a>
+Previous: <a rel="previous" accesskey="p" href="#Installing-Netperf-Bits">Installing Netperf Bits</a>,
Up: <a rel="up" accesskey="u" href="#Installing-Netperf">Installing Netperf</a>
-<br>
+
</div>
<h3 class="section">2.3 Verifying Installation</h3>
@@ -498,10 +506,11 @@
</pre>
<div class="node">
<p><hr>
-<a name="The-Design-of-Netperf"></a>Next: <a rel="next" accesskey="n" href="#Global-Command_002dline-Options">Global Command-line Options</a>,
+<a name="The-Design-of-Netperf"></a>
+Next: <a rel="next" accesskey="n" href="#Global-Command_002dline-Options">Global Command-line Options</a>,
Previous: <a rel="previous" accesskey="p" href="#Installing-Netperf">Installing Netperf</a>,
Up: <a rel="up" accesskey="u" href="#Top">Top</a>
-<br>
+
</div>
<h2 class="chapter">3 The Design of Netperf</h2>
@@ -538,9 +547,10 @@
<div class="node">
<p><hr>
-<a name="CPU-Utilization"></a>Previous: <a rel="previous" accesskey="p" href="#The-Design-of-Netperf">The Design of Netperf</a>,
+<a name="CPU-Utilization"></a>
+Previous: <a rel="previous" accesskey="p" href="#The-Design-of-Netperf">The Design of Netperf</a>,
Up: <a rel="up" accesskey="u" href="#The-Design-of-Netperf">The Design of Netperf</a>
-<br>
+
</div>
<h3 class="section">3.1 CPU Utilization</h3>
@@ -577,7 +587,7 @@
<dt><code>U</code><dd>The CPU utilization measurement mechanism was unknown to netperf or
netperf/netserver was not compiled to include CPU utilization
measurements. The code for the null CPU utilization mechanism can be
-found in <span class="file">src/netcpu_none.c</span>.
+found in <samp><span class="file">src/netcpu_none.c</span></samp>.
<br><dt><code>I</code><dd>An HP-UX-specific CPU utilization mechanism whereby the kernel
incremented a per-CPU counter by one for each trip through the idle
loop. This mechanism was only available on specially-compiled HP-UX
@@ -597,8 +607,8 @@
(HP-UX 11.23 and later). The former requires calibration, the latter
does not. Values in either case are retrieved via one of the pstat(2)
family of calls, hence the use of the letter <code>P</code>. The code for
-these mechanisms is found in <span class="file">src/netcpu_pstat.c</span> and
-<span class="file">src/netcpu_pstatnew.c</span> respectively.
+these mechanisms is found in <samp><span class="file">src/netcpu_pstat.c</span></samp> and
+<samp><span class="file">src/netcpu_pstatnew.c</span></samp> respectively.
<br><dt><code>K</code><dd>A Solaris-specific CPU utilization mechanism where by the kernel
keeps track of ticks (eg HZ) spent in the idle loop. This method is
statistical and is known to be inaccurate when the interrupt rate is
@@ -606,7 +616,7 @@
from idle. The value is retrieved via a kstat() call - hence the use
of the letter <code>K</code>. Since this mechanism uses units of ticks (HZ)
the calibration value should invariably match HZ. (Eg 100) The code
-for this mechanism is implemented in <span class="file">src/netcpu_kstat.c</span>.
+for this mechanism is implemented in <samp><span class="file">src/netcpu_kstat.c</span></samp>.
<br><dt><code>M</code><dd>A Solaris-specific mechanism available on Solaris 10 and latter which
uses the new microstate accounting mechanisms. There are two, alas,
overlapping, mechanisms. The first tracks nanoseconds spent in user,
@@ -618,28 +628,28 @@
without issues. The values are retrieved via kstat() calls, but the
letter code is set to <code>M</code> to distinguish this mechanism from the
even less accurate <code>K</code> mechanism. The code for this mechanism is
-implemented in <span class="file">src/netcpu_kstat10.c</span>.
+implemented in <samp><span class="file">src/netcpu_kstat10.c</span></samp>.
<br><dt><code>L</code><dd>A mechanism based on “looper”or “soaker” processes which sit in
tight loops counting as fast as they possibly can. This mechanism
starts a looper process for each known CPU on the system. The effect
of processor hyperthreading on the mechanism is not yet known. This
mechanism definitely requires calibration. The code for the
-“looper”mechanism can be found in <span class="file">src/netcpu_looper.c</span>
+“looper”mechanism can be found in <samp><span class="file">src/netcpu_looper.c</span></samp>
<br><dt><code>N</code><dd>A Microsoft Windows-specific mechanism, the code for which can be
-found in <span class="file">src/netcpu_ntperf.c</span>. This mechanism too is based on
+found in <samp><span class="file">src/netcpu_ntperf.c</span></samp>. This mechanism too is based on
what appears to be a form of micro-state accounting and requires no
calibration. On laptops, or other systems which may dynamically alter
the CPU frequency to minimize power consumtion, it has been suggested
that this mechanism may become slightly confsed, in which case using
BIOS settings to disable the power saving would be indicated.
- <br><dt><code>S</code><dd>This mechanism uses <span class="file">/proc/stat</span> on Linux to retrieve time
+ <br><dt><code>S</code><dd>This mechanism uses <samp><span class="file">/proc/stat</span></samp> on Linux to retrieve time
(ticks) spent in idle mode. It is thought but not known to be
reasonably accurate. The code for this mechanism can be found in
-<span class="file">src/netcpu_procstat.c</span>.
+<samp><span class="file">src/netcpu_procstat.c</span></samp>.
<br><dt><code>C</code><dd>A mechanism somewhat similar to <code>S</code> but using the sysctl() call
on BSD-like Operating systems (*BSD and MacOS X). The code for this
-mechanism can be found in <span class="file">src/netcpu_sysctl.c</span>.
+mechanism can be found in <samp><span class="file">src/netcpu_sysctl.c</span></samp>.
<br><dt><code>Others</code><dd>Other mechanisms included in netperf in the past have included using
the times() and getrusage() calls. These calls are actually rather
poorly suited to the task of measuring CPU overhead for networking as
@@ -687,10 +697,12 @@
<div class="node">
<p><hr>
-<a name="Global-Command_002dline-Options"></a>Next: <a rel="next" accesskey="n" href="#Using-Netperf-to-Measure-Bulk-Data-Transfer">Using Netperf to Measure Bulk Data Transfer</a>,
+<a name="Global-Command-line-Options"></a>
+<a name="Global-Command_002dline-Options"></a>
+Next: <a rel="next" accesskey="n" href="#Using-Netperf-to-Measure-Bulk-Data-Transfer">Using Netperf to Measure Bulk Data Transfer</a>,
Previous: <a rel="previous" accesskey="p" href="#The-Design-of-Netperf">The Design of Netperf</a>,
Up: <a rel="up" accesskey="u" href="#Top">Top</a>
-<br>
+
</div>
<h2 class="chapter">4 Global Command-line Options</h2>
@@ -698,7 +710,7 @@
<p>This section describes each of the global command-line options
available in the netperf and netserver binaries. Essentially, it is
an expanded version of the usage information displayed by netperf or
-netserver when invoked with the <span class="option">-h</span> global command-line
+netserver when invoked with the <samp><span class="option">-h</span></samp> global command-line
option.
<ul class="menu">
@@ -708,10 +720,12 @@
<div class="node">
<p><hr>
-<a name="Command_002dline-Options-Syntax"></a>Next: <a rel="next" accesskey="n" href="#Global-Options">Global Options</a>,
+<a name="Command-line-Options-Syntax"></a>
+<a name="Command_002dline-Options-Syntax"></a>
+Next: <a rel="next" accesskey="n" href="#Global-Options">Global Options</a>,
Previous: <a rel="previous" accesskey="p" href="#Global-Command_002dline-Options">Global Command-line Options</a>,
Up: <a rel="up" accesskey="u" href="#Global-Command_002dline-Options">Global Command-line Options</a>
-<br>
+
</div>
<!-- node-name, next, previous, up -->
@@ -720,7 +734,7 @@
<p>Revision 1.8 of netperf introduced enough new functionality to overrun
the English alphabet for mnemonic command-line option names, and the
author was not and is not quite ready to switch to the contemporary
-<span class="option">--mumble</span> style of command-line options. (Call him a Luddite).
+<samp><span class="option">--mumble</span></samp> style of command-line options. (Call him a Luddite).
<p>For this reason, the command-line options were split into two parts -
the first are the global command-line options. They are options that
@@ -744,9 +758,10 @@
<div class="node">
<p><hr>
-<a name="Global-Options"></a>Previous: <a rel="previous" accesskey="p" href="#Command_002dline-Options-Syntax">Command-line Options Syntax</a>,
+<a name="Global-Options"></a>
+Previous: <a rel="previous" accesskey="p" href="#Command_002dline-Options-Syntax">Command-line Options Syntax</a>,
Up: <a rel="up" accesskey="u" href="#Global-Command_002dline-Options">Global Command-line Options</a>
-<br>
+
</div>
<!-- node-name, next, previous, up -->
@@ -759,18 +774,18 @@
schemes, which can have a measurable effect on performance. If the
page size for the system were 4096 bytes, and you want to pass
page-aligned buffers beginning on page boundaries, you could use
-<span class="samp">-a 4096</span>. By default the units are bytes, but suffix of “G,”
+`<samp><span class="samp">-a 4096</span></samp>'. By default the units are bytes, but suffix of “G,”
“M,” or “K” will specify the units to be 2^30 (GB), 2^20 (MB) or
2^10 (KB) respectively. A suffix of “g,” “m” or “k” will specify
units of 10^9, 10^6 or 10^3 bytes respectively. [Default: 8 bytes]
- <br><dt><code>-A <sizespec></code><dd>This option is identical to the <span class="option">-a</span> option with the difference
+ <br><dt><code>-A <sizespec></code><dd>This option is identical to the <samp><span class="option">-a</span></samp> option with the difference
being it affects alignments for the remote system.
<br><dt><code>-b <size></code><dd>This option is only present when netperf has been configure with
–enable-intervals=yes prior to compilation. It sets the size of the
burst of send calls in a _STREAM test. When used in conjunction with
-the <span class="option">-w</span> option it can cause the rate at which data is sent to
+the <samp><span class="option">-w</span></samp> option it can cause the rate at which data is sent to
be “paced.”
<br><dt><code>-c [rate]</code><dd>This option will ask that CPU utilization and service demand be
@@ -782,7 +797,7 @@
[Default: no CPU measurements]
<br><dt><code>-C [rate]</code><dd>This option requests CPU utilization and service demand calculations
-for the remote system. It is otherwise identical to the <span class="option">-c</span>
+for the remote system. It is otherwise identical to the <samp><span class="option">-c</span></samp>
option.
<br><dt><code>-d</code><dd>Each instance of this option will increase the quantity of debugging
@@ -790,7 +805,7 @@
high enough, it may have a measurable effect on performance.
Debugging information for the local system is printed to stdout.
Debugging information for the remote system is sent by default to the
-file <span class="file">/tmp/netperf.debug</span>. [Default: no debugging output]
+file <samp><span class="file">/tmp/netperf.debug</span></samp>. [Default: no debugging output]
<br><dt><code>-D [interval,units]</code><dd>This option is only available when netperf is configured with
–enable-demo=yes. When set, it will cause netperf to emit periodic
@@ -845,21 +860,21 @@
“6” to request IPv6 only addressing. A value of “0” can be used
to request either IPv4 or IPv6 addressing as name resolution dictates.
- <p>By default, the options set with the global <span class="option">-H</span> option are
+ <p>By default, the options set with the global <samp><span class="option">-H</span></samp> option are
inherited by the test for their data connections, unless a
-test-specific <span class="option">-H</span> option is specified.
+test-specific <samp><span class="option">-H</span></samp> option is specified.
- <p>If a <span class="option">-H</span> option follows either the <span class="option">-4</span> or <span class="option">-6</span>
+ <p>If a <samp><span class="option">-H</span></samp> option follows either the <samp><span class="option">-4</span></samp> or <samp><span class="option">-6</span></samp>
options, the family setting specified with the -H option will override
-the <span class="option">-4</span> or <span class="option">-6</span> options for the remote address
+the <samp><span class="option">-4</span></samp> or <samp><span class="option">-6</span></samp> options for the remote address
family. If no address family is specified, settings from a previous
-<span class="option">-4</span> or <span class="option">-6</span> option will remain. In a nutshell, the
+<samp><span class="option">-4</span></samp> or <samp><span class="option">-6</span></samp> option will remain. In a nutshell, the
last explicit global command-line option wins.
<p>[Default: “localhost” for the remote name/IP address and “0” (eg
AF_UNSPEC) for the remote address family.]
- <br><dt><code>-L <optionspec></code><dd>This option is identical to the <span class="option">-H</span> option with the difference
+ <br><dt><code>-L <optionspec></code><dd>This option is identical to the <samp><span class="option">-H</span></samp> option with the difference
being it sets the _local_ hostname/IP and/or address family
information. This option is generally unnecessary, but can be useful
when you wish to make sure that the netperf control and data
@@ -879,13 +894,13 @@
</pre>
<p>asks netperf to be 99% confident that the measured mean values for
throughput and CPU utilization are within +/- 2.5% of the “real”
-mean values. If the <span class="option">-i</span> option is specified and the
-<span class="option">-I</span> option is omitted, the confidence defaults to 99% and the
+mean values. If the <samp><span class="option">-i</span></samp> option is specified and the
+<samp><span class="option">-I</span></samp> option is omitted, the confidence defaults to 99% and the
width to 5% (giving +/- 2.5%)
<p>If netperf calculates that the desired confidence intervals have not
been met, it emits a noticeable warning that cannot be suppressed with
-the <span class="option">-P</span> or <span class="option">-v</span> options:
+the <samp><span class="option">-P</span></samp> or <samp><span class="option">-v</span></samp> options:
<pre class="example"> netperf -H tardy.cup -i 3 -I 99,5
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to tardy.cup.hp.com (15.244.44.58) port 0 AF_INET : +/-2.5% 99% conf.
@@ -907,9 +922,9 @@
<p>Where we see that netperf did not meet the desired convidence
intervals. Instead of being 99% confident it was within +/- 2.5% of
the real mean value of throughput it is only confident it was within
-+/-3.4%. In this example, increasing the <span class="option">-i</span> option
++/-3.4%. In this example, increasing the <samp><span class="option">-i</span></samp> option
(described below) and/or increasing the iteration length with the
-<span class="option">-l</span> option might resolve the situation.
+<samp><span class="option">-l</span></samp> option might resolve the situation.
<br><dt><code>-i <sizespec></code><dd>This option enables the calculation of confidence intervals and sets
the minimum and maximum number of iterations to run in attempting to
@@ -921,7 +936,7 @@
desired confidence interval, or the maximum number of iterations,
whichever comes first.
- <p>If the <span class="option">-I</span> option is specified and the <span class="option">-i</span> option
+ <p>If the <samp><span class="option">-I</span></samp> option is specified and the <samp><span class="option">-i</span></samp> option
omitted the maximum number of iterations is set to 10 and the minimum
to three.
@@ -937,7 +952,7 @@
be limited by transaction or byte count.
<p>In some situations, individual iterations of a test may run for longer
-for the number of seconds specified by the <span class="option">-l</span> option. In
+for the number of seconds specified by the <samp><span class="option">-l</span></samp> option. In
particular, this may occur for those tests where the socket buffer
size(s) are significantly longer than the bandwidthXdelay product of
the link(s) over which the data connection passes, or those tests
@@ -953,10 +968,10 @@
<p>Note that this option does _not_ set the number of CPUs on the system
running netserver. When netperf/netserver cannot automagically
determine the number of CPUs that can only be set for netserver via a
-netserver <span class="option">-n</span> command-line option.
+netserver <samp><span class="option">-n</span></samp> command-line option.
<br><dt><code>-o <sizespec></code><dd>The value(s) passed-in with this option will be used as an offset
-added to the alignment specified with the <span class="option">-a</span> option. For
+added to the alignment specified with the <samp><span class="option">-a</span></samp> option. For
example:
<pre class="example"> -o 3 -a 4096
</pre>
@@ -964,8 +979,8 @@
begin three bytes past an address aligned to 4096 bytes. [Default: 0
bytes]
- <br><dt><code>-O <sizespec></code><dd>This option behaves just as the <span class="option">-o</span> option by on the remote
-system and in conjunction with the <span class="option">-A</span> option. [Default: 0
+ <br><dt><code>-O <sizespec></code><dd>This option behaves just as the <samp><span class="option">-o</span></samp> option by on the remote
+system and in conjunction with the <samp><span class="option">-A</span></samp> option. [Default: 0
bytes]
<br><dt><code>-p <optionspec></code><dd>The first value of the optionspec passed-in with this option tells
@@ -988,7 +1003,7 @@
is looking to run netperf through those evil, end-to-end breaking
things known as firewalls.
- <br><dt><code>-P 0|1</code><dd>A value of “1” for the <span class="option">-P</span> option will enable display of
+ <br><dt><code>-P 0|1</code><dd>A value of “1” for the <samp><span class="option">-P</span></samp> option will enable display of
the test banner. A value of “0” will disable display of the test
banner. One might want to disable display of the test banner when
running the same basic test type (eg TCP_STREAM) multiple times in
@@ -1009,22 +1024,22 @@
Not all tests are always compiled into netperf. In particular, the
“XTI,” “SCTP,” “UNIX,” and “DL*” tests are only included in
netperf when configured with
-<span class="option">--enable-[xti|sctp|unix|dlpi]=yes</span>.
+<samp><span class="option">--enable-[xti|sctp|unix|dlpi]=yes</span></samp>.
- <p>Netperf only runs one type of test no matter how many <span class="option">-t</span>
-options may be present on the command-line. The last <span class="option">-t</span>
+ <p>Netperf only runs one type of test no matter how many <samp><span class="option">-t</span></samp>
+options may be present on the command-line. The last <samp><span class="option">-t</span></samp>
global command-line option will determine the test to be
run. [Default: TCP_STREAM]
<br><dt><code>-v verbosity</code><dd>This option controls how verbose netperf will be in its output, and is
-often used in conjunction with the <span class="option">-P</span> option. If the
+often used in conjunction with the <samp><span class="option">-P</span></samp> option. If the
verbosity is set to a value of “0” then only the test's SFM (Single
-Figure of Merit) is displayed. If local <a href="#CPU-Utilization">CPU utilization</a> is requested via the <span class="option">-c</span> option then the SFM is
+Figure of Merit) is displayed. If local <a href="#CPU-Utilization">CPU utilization</a> is requested via the <samp><span class="option">-c</span></samp> option then the SFM is
the local service demand. Othersise, if remote CPU utilization is
-requested via the <span class="option">-C</span> option then the SFM is the remote
+requested via the <samp><span class="option">-C</span></samp> option then the SFM is the remote
service demand. If neither local nor remote CPU utilization are
requested the SFM will be the measured throughput or transaction rate
-as implied by the test specified with the <span class="option">-t</span> option.
+as implied by the test specified with the <samp><span class="option">-t</span></samp> option.
<p>If the verbosity level is set to “1” then the “normal” netperf
result output for each test is displayed.
@@ -1034,11 +1049,11 @@
send or recv calls made and the average number of bytes per send or
recv call, or a histogram of the time spent in each send() call or for
each transaction if netperf was configured with
-<span class="option">--enable-histogram=yes</span>. [Default: 1 - normal verbosity]
+<samp><span class="option">--enable-histogram=yes</span></samp>. [Default: 1 - normal verbosity]
- <br><dt><code>-w time</code><dd>If netperf was configured with <span class="option">--enable-intervals=yes</span> then
+ <br><dt><code>-w time</code><dd>If netperf was configured with <samp><span class="option">--enable-intervals=yes</span></samp> then
this value will set the inter-burst time to time milliseconds, and the
-<span class="option">-b</span> option will set the number of sends per burst. The actual
+<samp><span class="option">-b</span></samp> option will set the number of sends per burst. The actual
inter-burst time may vary depending on the system's timer resolution.
<br><dt><code>-W <sizespec></code><dd>This option controls the number of buffers in the send (first or only
@@ -1046,22 +1061,22 @@
some benchmarks, netperf does not continuously send or receive from a
single buffer. Instead it rotates through a ring of
buffers. [Default: One more than the size of the send or receive
-socket buffer sizes (<span class="option">-s</span> and/or <span class="option">-S</span> options) divided
-by the send <span class="option">-m</span> or receive <span class="option">-M</span> buffer size
+socket buffer sizes (<samp><span class="option">-s</span></samp> and/or <samp><span class="option">-S</span></samp> options) divided
+by the send <samp><span class="option">-m</span></samp> or receive <samp><span class="option">-M</span></samp> buffer size
respectively]
<br><dt><code>-4</code><dd>Specifying this option will set both the local and remote address
families to AF_INET - that is use only IPv4 addresses on the control
-connection. This can be overridden by a subsequent <span class="option">-6</span>,
-<span class="option">-H</span> or <span class="option">-L</span> option. Basically, the last option
+connection. This can be overridden by a subsequent <samp><span class="option">-6</span></samp>,
+<samp><span class="option">-H</span></samp> or <samp><span class="option">-L</span></samp> option. Basically, the last option
explicitly specifying an address family wins. Unless overridden by a
test-specific option, this will be inherited for the data connection
as well.
<br><dt><code>-6</code><dd>Specifying this option will set both local and and remote address
families to AF_INET6 - that is use only IPv6 addresses on the control
-connection. This can be overridden by a subsequent <span class="option">-4</span>,
-<span class="option">-H</span> or <span class="option">-L</span> option. Basically, the last address family
+connection. This can be overridden by a subsequent <samp><span class="option">-4</span></samp>,
+<samp><span class="option">-H</span></samp> or <samp><span class="option">-L</span></samp> option. Basically, the last address family
explicitly specified wins. Unless overridden by a test-specific
option, this will be inherited for the data connection as well.
@@ -1069,10 +1084,11 @@
<div class="node">
<p><hr>
-<a name="Using-Netperf-to-Measure-Bulk-Data-Transfer"></a>Next: <a rel="next" accesskey="n" href="#Using-Netperf-to-Measure-Request_002fResponse">Using Netperf to Measure Request/Response</a>,
+<a name="Using-Netperf-to-Measure-Bulk-Data-Transfer"></a>
+Next: <a rel="next" accesskey="n" href="#Using-Netperf-to-Measure-Request_002fResponse">Using Netperf to Measure Request/Response</a>,
Previous: <a rel="previous" accesskey="p" href="#Global-Command_002dline-Options">Global Command-line Options</a>,
Up: <a rel="up" accesskey="u" href="#Top">Top</a>
-<br>
+
</div>
<h2 class="chapter">5 Using Netperf to Measure Bulk Data Transfer</h2>
@@ -1090,10 +1106,11 @@
<div class="node">
<p><hr>
-<a name="Issues-in-Bulk-Transfer"></a>Next: <a rel="next" accesskey="n" href="#Options-common-to-TCP-UDP-and-SCTP-tests">Options common to TCP UDP and SCTP tests</a>,
+<a name="Issues-in-Bulk-Transfer"></a>
+Next: <a rel="next" accesskey="n" href="#Options-common-to-TCP-UDP-and-SCTP-tests">Options common to TCP UDP and SCTP tests</a>,
Previous: <a rel="previous" accesskey="p" href="#Using-Netperf-to-Measure-Bulk-Data-Transfer">Using Netperf to Measure Bulk Data Transfer</a>,
Up: <a rel="up" accesskey="u" href="#Using-Netperf-to-Measure-Bulk-Data-Transfer">Using Netperf to Measure Bulk Data Transfer</a>
-<br>
+
</div>
<!-- node-name, next, previous, up -->
@@ -1138,7 +1155,7 @@
retransmission timeout has happened, the flow or connection has sat
idle for a considerable length of time.
- <p>On many platforms, some variant on the <span class="command">netstat</span> command can
+ <p>On many platforms, some variant on the <samp><span class="command">netstat</span></samp> command can
be used to retrieve statistics about packet loss and
retransmission. For example:
<pre class="example"> netstat -p tcp
@@ -1159,19 +1176,20 @@
</pre>
<p>is indicated. The
<a href="ftp://ftp.cup.hp.com/dist/networking/tools/">beforeafter</a> utility
-can be used to subtract the statistics in <span class="file">before</span> from the
-statistics in <span class="file">after</span>
+can be used to subtract the statistics in <samp><span class="file">before</span></samp> from the
+statistics in <samp><span class="file">after</span></samp>
<pre class="example"> beforeafter before after > delta
</pre>
- <p>and then one can look at the statistics in <span class="file">delta</span>. While it was
+ <p>and then one can look at the statistics in <samp><span class="file">delta</span></samp>. While it was
written with HP-UX's netstat in mind, the
<a href="ftp://ftp.cup.hp.com/dist/networking/briefs/annotated_netstat.txt">annotated netstat</a> writeup may be helpful with other platforms as well.
<div class="node">
<p><hr>
-<a name="Options-common-to-TCP-UDP-and-SCTP-tests"></a>Previous: <a rel="previous" accesskey="p" href="#Issues-in-Bulk-Transfer">Issues in Bulk Transfer</a>,
+<a name="Options-common-to-TCP-UDP-and-SCTP-tests"></a>
+Previous: <a rel="previous" accesskey="p" href="#Issues-in-Bulk-Transfer">Issues in Bulk Transfer</a>,
Up: <a rel="up" accesskey="u" href="#Using-Netperf-to-Measure-Bulk-Data-Transfer">Using Netperf to Measure Bulk Data Transfer</a>
-<br>
+
</div>
<!-- node-name, next, previous, up -->
@@ -1191,13 +1209,13 @@
<br><dt><code>-H <optionspec></code><dd>Normally, the remote hostname|IP and address family information is
inherited from the settings for the control connection (eg global
-command-line <span class="option">-H</span>, <span class="option">-4</span> and/or <span class="option">-6</span> options).
-The test-specific <span class="option">-H</span> will override those settings for the
+command-line <samp><span class="option">-H</span></samp>, <samp><span class="option">-4</span></samp> and/or <samp><span class="option">-6</span></samp> options).
+The test-specific <samp><span class="option">-H</span></samp> will override those settings for the
data (aka test) connection only. Settings for the control connection
are left unchanged.
- <br><dt><code>-L <optionspec></code><dd>The test-specific <span class="option">-L</span> option is identical to the test-specific
-<span class="option">-H</span> option except it affects the local hostname|IP and address
+ <br><dt><code>-L <optionspec></code><dd>The test-specific <samp><span class="option">-L</span></samp> option is identical to the test-specific
+<samp><span class="option">-H</span></samp> option except it affects the local hostname|IP and address
family information. As with its global command-line counterpart, this
is generally only useful when measuring though those evil, end-to-end
breaking things called firewalls.
@@ -1206,7 +1224,7 @@
_STREAM test. Note that this may have only an indirect effect on the
size of the packets sent over the network, and certain Layer 4
protocols do _not_ preserve or enforce message boundaries, so setting
-<span class="option">-m</span> for the send size does not necessarily mean the receiver
+<samp><span class="option">-m</span></samp> for the send size does not necessarily mean the receiver
will receive that many bytes at any one time. By default the units are
bytes, but suffix of “G,” “M,” or “K” will specify the units to
be 2^30 (GB), 2^20 (MB) or 2^10 (KB) respectively. A suffix of “g,”
@@ -1216,7 +1234,7 @@
</pre>
<p>will set the size to 32KB or 32768 bytes. [Default: the local send
socket buffer size for the connection - either the system's default or
-the value set via the <span class="option">-s</span> option.]
+the value set via the <samp><span class="option">-s</span></samp> option.]
<br><dt><code>-M bytes</code><dd>Set the size of the buffer passed-in to the “recv” calls of a
_STREAM test. This will be an upper bound on the number of bytes
@@ -1229,7 +1247,7 @@
</pre>
<p>will set the size to 32KB or 32768 bytes. [Default: the remote receive
socket buffer size for the data connection - either the system's
-default or the value set via the <span class="option">-S</span> option.]
+default or the value set via the <samp><span class="option">-S</span></samp> option.]
<br><dt><code>-P <optionspec></code><dd>Set the local and/or remote port numbers for the data connection.
@@ -1277,11 +1295,11 @@
<br><dt><code>-4</code><dd>Set the local and remote address family for the data connection to
AF_INET - ie use IPv4 addressing only. Just as with their global
-command-line counterparts the last of the <span class="option">-4</span>, <span class="option">-6</span>,
-<span class="option">-H</span> or <span class="option">-L</span> option wins for their respective address
+command-line counterparts the last of the <samp><span class="option">-4</span></samp>, <samp><span class="option">-6</span></samp>,
+<samp><span class="option">-H</span></samp> or <samp><span class="option">-L</span></samp> option wins for their respective address
families.
- <br><dt><code>-6</code><dd>This option is identical to its <span class="option">-4</span> cousin, but requests IPv6
+ <br><dt><code>-6</code><dd>This option is identical to its <samp><span class="option">-4</span></samp> cousin, but requests IPv6
addresses for the local and remote ends of the data connection.
</dl>
@@ -1302,10 +1320,12 @@
<div class="node">
<p><hr>
-<a name="TCP_005fSTREAM"></a>Next: <a rel="next" accesskey="n" href="#TCP_005fMAERTS">TCP_MAERTS</a>,
+<a name="TCP_STREAM"></a>
+<a name="TCP_005fSTREAM"></a>
+Next: <a rel="next" accesskey="n" href="#TCP_005fMAERTS">TCP_MAERTS</a>,
Previous: <a rel="previous" accesskey="p" href="#Options-common-to-TCP-UDP-and-SCTP-tests">Options common to TCP UDP and SCTP tests</a>,
Up: <a rel="up" accesskey="u" href="#Options-common-to-TCP-UDP-and-SCTP-tests">Options common to TCP UDP and SCTP tests</a>
-<br>
+
</div>
<h4 class="subsection">5.2.1 TCP_STREAM</h4>
@@ -1329,11 +1349,11 @@
explicit flush operation or the connection is closed. At present
netperf does not perform an explicit flush operations. Setting
TCP_CORK may improve the bitrate of tests where the “send size”
-(<span class="option">-m</span> option) is smaller than the MSS. It should also improve
+(<samp><span class="option">-m</span></samp> option) is smaller than the MSS. It should also improve
(make smaller) the service demand.
<p>The Linux tcp(7) manpage states that TCP_CORK cannot be used in
-conjunction with TCP_NODELAY (set via the <span class="option">-d</span> option), however
+conjunction with TCP_NODELAY (set via the <samp><span class="option">-d</span></samp> option), however
netperf does not validate command-line options to enforce that.
<br><dt><code>-D</code><dd>This option will set TCP_NODELAY on the data connection on those
@@ -1341,15 +1361,15 @@
as the Nagle Algorithm, which is intended to make the segments TCP
sends as large as reasonably possible. Setting TCP_NODELAY for a
TCP_STREAM test should either have no effect when the send size
-(<span class="option">-m</span> option) is larger than the MSS or will decrease reported
+(<samp><span class="option">-m</span></samp> option) is larger than the MSS or will decrease reported
bitrate and increase service demand when the send size is smaller than
the MSS. This stems from TCP_NODELAY causing each sub-MSS send to be
its own TCP segment rather than being aggregated with other small
sends. This means more trips up and down the protocol stack per KB of
data transferred, which means greater CPU utilization.
- <p>If setting TCP_NODELAY with <span class="option">-D</span> affects throughput and/or
-service demand for tests where the send size (<span class="option">-m</span>) is larger
+ <p>If setting TCP_NODELAY with <samp><span class="option">-D</span></samp> affects throughput and/or
+service demand for tests where the send size (<samp><span class="option">-m</span></samp>) is larger
than the MSS it suggests the TCP/IP stack's implementation of the
Nagle Algorithm _may_ be broken, perhaps interpreting the Nagle
Algorithm on a segment by segment basis rather than the proper user
@@ -1379,10 +1399,12 @@
<div class="node">
<p><hr>
-<a name="TCP_005fMAERTS"></a>Next: <a rel="next" accesskey="n" href="#TCP_005fSENDFILE">TCP_SENDFILE</a>,
+<a name="TCP_MAERTS"></a>
+<a name="TCP_005fMAERTS"></a>
+Next: <a rel="next" accesskey="n" href="#TCP_005fSENDFILE">TCP_SENDFILE</a>,
Previous: <a rel="previous" accesskey="p" href="#TCP_005fSTREAM">TCP_STREAM</a>,
Up: <a rel="up" accesskey="u" href="#Options-common-to-TCP-UDP-and-SCTP-tests">Options common to TCP UDP and SCTP tests</a>
-<br>
+
</div>
<!-- node-name, next, previous, up -->
@@ -1390,13 +1412,13 @@
<p>A TCP_MAERTS (MAERTS is STREAM backwards) test is “just like” a
<a href="#TCP_005fSTREAM">TCP_STREAM</a> test except the data flows from the netserver to the
-netperf. The global command-line <span class="option">-F</span> option is ignored for
-this test type. The test-specific command-line <span class="option">-C</span> option is
+netperf. The global command-line <samp><span class="option">-F</span></samp> option is ignored for
+this test type. The test-specific command-line <samp><span class="option">-C</span></samp> option is
ignored for this test type.
<p>Here is an example of a TCP_MAERTS test between the same two systems
as in the example for the <a href="#TCP_005fSTREAM">TCP_STREAM</a> test. This time we request
-larger socket buffers with <span class="option">-s</span> and <span class="option">-S</span> options:
+larger socket buffers with <samp><span class="option">-s</span></samp> and <samp><span class="option">-S</span></samp> options:
<pre class="example"> $ netperf -H lag -t TCP_MAERTS -- -s 128K -S 128K
TCP MAERTS TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to lag.hpl.hp.com (15.4.89.214) port 0 AF_INET
@@ -1415,10 +1437,12 @@
<div class="node">
<p><hr>
-<a name="TCP_005fSENDFILE"></a>Next: <a rel="next" accesskey="n" href="#UDP_005fSTREAM">UDP_STREAM</a>,
+<a name="TCP_SENDFILE"></a>
+<a name="TCP_005fSENDFILE"></a>
+Next: <a rel="next" accesskey="n" href="#UDP_005fSTREAM">UDP_STREAM</a>,
Previous: <a rel="previous" accesskey="p" href="#TCP_005fMAERTS">TCP_MAERTS</a>,
Up: <a rel="up" accesskey="u" href="#Options-common-to-TCP-UDP-and-SCTP-tests">Options common to TCP UDP and SCTP tests</a>
-<br>
+
</div>
<!-- node-name, next, previous, up -->
@@ -1442,9 +1466,9 @@
no opportunity to reserve space for headers and so a packet will be
contained in two or more buffers.
- <p>The <a href="#Global-Options">global <span class="option">-F</span> option</a> is required for this test and it must
-specify a file of at least the size of the send ring (See <a href="#Global-Options">the global <span class="option">-W</span> option</a>.) multiplied by the send size
-(See <a href="#Options-common-to-TCP-UDP-and-SCTP-tests">the test-specific <span class="option">-m</span> option</a>.). All other TCP-specific options are available
+ <p>The <a href="#Global-Options">global <samp><span class="option">-F</span></samp> option</a> is required for this test and it must
+specify a file of at least the size of the send ring (See <a href="#Global-Options">the global <samp><span class="option">-W</span></samp> option</a>.) multiplied by the send size
+(See <a href="#Options-common-to-TCP-UDP-and-SCTP-tests">the test-specific <samp><span class="option">-m</span></samp> option</a>.). All other TCP-specific options are available
and optional.
<p>In this first example:
@@ -1468,10 +1492,12 @@
<div class="node">
<p><hr>
-<a name="UDP_005fSTREAM"></a>Next: <a rel="next" accesskey="n" href="#XTI_005fTCP_005fSTREAM">XTI_TCP_STREAM</a>,
+<a name="UDP_STREAM"></a>
+<a name="UDP_005fSTREAM"></a>
+Next: <a rel="next" accesskey="n" href="#XTI_005fTCP_005fSTREAM">XTI_TCP_STREAM</a>,
Previous: <a rel="previous" accesskey="p" href="#TCP_005fSENDFILE">TCP_SENDFILE</a>,
Up: <a rel="up" accesskey="u" href="#Options-common-to-TCP-UDP-and-SCTP-tests">Options common to TCP UDP and SCTP tests</a>
-<br>
+
</div>
<h4 class="subsection">5.2.4 UDP_STREAM</h4>
@@ -1482,7 +1508,7 @@
<p>A UDP_STREAM test has no end-to-end flow control - UDP provides none
and neither does netperf. However, if you wish, you can configure
netperf with <code>--enable-intervals=yes</code> to enable the global
-command-line <span class="option">-b</span> and <span class="option">-w</span> options to pace bursts of
+command-line <samp><span class="option">-b</span></samp> and <samp><span class="option">-w</span></samp> options to pace bursts of
traffic onto the network.
<p>This has a number of implications.
@@ -1512,15 +1538,15 @@
side. In this case, 105672 - 104844 or 828 messages did not make it
all the way to the remote netserver process.
- <p>If the value of the <span class="option">-m</span> option is larger than the local send
-socket buffer size (<span class="option">-s</span> option) netperf will likely abort with
+ <p>If the value of the <samp><span class="option">-m</span></samp> option is larger than the local send
+socket buffer size (<samp><span class="option">-s</span></samp> option) netperf will likely abort with
an error message about how the send call failed:
<pre class="example"> netperf -t UDP_STREAM -H 192.168.2.125
UDP UNIDIRECTIONAL SEND TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.2.125 (192.168.2.125) port 0 AF_INET
udp_send: data send error: Message too long
</pre>
- <p>If the value of the <span class="option">-m</span> option is larger than the remote
+ <p>If the value of the <samp><span class="option">-m</span></samp> option is larger than the remote
socket receive buffer, the reported receive throughput will likely be
zero as the remote UDP will discard the messages as being too large to
fit into the socket buffer.
@@ -1536,17 +1562,19 @@
</pre>
<div class="node">
<p><hr>
-<a name="XTI_005fTCP_005fSTREAM"></a>Next: <a rel="next" accesskey="n" href="#XTI_005fUDP_005fSTREAM">XTI_UDP_STREAM</a>,
+<a name="XTI_TCP_STREAM"></a>
+<a name="XTI_005fTCP_005fSTREAM"></a>
+Next: <a rel="next" accesskey="n" href="#XTI_005fUDP_005fSTREAM">XTI_UDP_STREAM</a>,
Previous: <a rel="previous" accesskey="p" href="#UDP_005fSTREAM">UDP_STREAM</a>,
Up: <a rel="up" accesskey="u" href="#Options-common-to-TCP-UDP-and-SCTP-tests">Options common to TCP UDP and SCTP tests</a>
-<br>
+
</div>
<h4 class="subsection">5.2.5 XTI_TCP_STREAM</h4>
<p>An XTI_TCP_STREAM test is simply a <a href="#TCP_005fSTREAM">TCP_STREAM</a> test using the XTI
-rather than BSD Sockets interface. The test-specific <span class="option">-X
-<devspec></span> option can be used to specify the name of the local and/or
+rather than BSD Sockets interface. The test-specific <samp><span class="option">-X
+<devspec></span></samp> option can be used to specify the name of the local and/or
remote XTI device files, which is required by the <code>t_open()</code> call
made by netperf XTI tests.
@@ -1556,17 +1584,19 @@
<div class="node">
<p><hr>
-<a name="XTI_005fUDP_005fSTREAM"></a>Next: <a rel="next" accesskey="n" href="#SCTP_005fSTREAM">SCTP_STREAM</a>,
+<a name="XTI_UDP_STREAM"></a>
+<a name="XTI_005fUDP_005fSTREAM"></a>
+Next: <a rel="next" accesskey="n" href="#SCTP_005fSTREAM">SCTP_STREAM</a>,
Previous: <a rel="previous" accesskey="p" href="#XTI_005fTCP_005fSTREAM">XTI_TCP_STREAM</a>,
Up: <a rel="up" accesskey="u" href="#Options-common-to-TCP-UDP-and-SCTP-tests">Options common to TCP UDP and SCTP tests</a>
-<br>
+
</div>
<h4 class="subsection">5.2.6 XTI_UDP_STREAM</h4>
<p>An XTI_UDP_STREAM test is simply a <a href="#UDP_005fSTREAM">UDP_STREAM</a> test using the XTI
-rather than BSD Sockets Interface. The test-specific <span class="option">-X
-<devspec></span> option can be used to specify the name of the local and/or
+rather than BSD Sockets Interface. The test-specific <samp><span class="option">-X
+<devspec></span></samp> option can be used to specify the name of the local and/or
remote XTI device files, which is required by the <code>t_open()</code> call
made by netperf XTI tests.
@@ -1576,20 +1606,22 @@
<div class="node">
<p><hr>
-<a name="SCTP_005fSTREAM"></a>Next: <a rel="next" accesskey="n" href="#DLCO_005fSTREAM">DLCO_STREAM</a>,
+<a name="SCTP_STREAM"></a>
+<a name="SCTP_005fSTREAM"></a>
+Next: <a rel="next" accesskey="n" href="#DLCO_005fSTREAM">DLCO_STREAM</a>,
Previous: <a rel="previous" accesskey="p" href="#XTI_005fUDP_005fSTREAM">XTI_UDP_STREAM</a>,
Up: <a rel="up" accesskey="u" href="#Options-common-to-TCP-UDP-and-SCTP-tests">Options common to TCP UDP and SCTP tests</a>
-<br>
+
</div>
<h4 class="subsection">5.2.7 SCTP_STREAM</h4>
<p>An SCTP_STREAM test is essentially a <a href="#TCP_005fSTREAM">TCP_STREAM</a> test using the SCTP
-rather than TCP. The <span class="option">-D</span> option will set SCTP_NODELAY, which
-is much like the TCP_NODELAY option for TCP. The <span class="option">-C</span> option
+rather than TCP. The <samp><span class="option">-D</span></samp> option will set SCTP_NODELAY, which
+is much like the TCP_NODELAY option for TCP. The <samp><span class="option">-C</span></samp> option
is not applicable to an SCTP test as there is no corresponding
SCTP_CORK option. The author is still figuring-out what the
-<span class="option">-N</span> option does :)
+<samp><span class="option">-N</span></samp> option does :)
<p>The SCTP_STREAM test is only present if netperf was configured with
<code>--enable-sctp=yes</code>. The remote netserver must have also been
@@ -1597,10 +1629,12 @@
<div class="node">
<p><hr>
-<a name="DLCO_005fSTREAM"></a>Next: <a rel="next" accesskey="n" href="#DLCL_005fSTREAM">DLCL_STREAM</a>,
+<a name="DLCO_STREAM"></a>
+<a name="DLCO_005fSTREAM"></a>
+Next: <a rel="next" accesskey="n" href="#DLCL_005fSTREAM">DLCL_STREAM</a>,
Previous: <a rel="previous" accesskey="p" href="#SCTP_005fSTREAM">SCTP_STREAM</a>,
Up: <a rel="up" accesskey="u" href="#Options-common-to-TCP-UDP-and-SCTP-tests">Options common to TCP UDP and SCTP tests</a>
-<br>
+
</div>
<h4 class="subsection">5.2.8 DLCO_STREAM</h4>
@@ -1610,9 +1644,9 @@
connection-oriented protocols. The DLPI test differs from the TCP
test in that its protocol operates only at the link-level and does not
include TCP-style segmentation and reassembly. This last difference
-means that the value passed-in with the <span class="option">-m</span> option must be
-less than the interface MTU. Otherwise, the <span class="option">-m</span> and
-<span class="option">-M</span> options are just like their TCP/UDP/SCTP counterparts.
+means that the value passed-in with the <samp><span class="option">-m</span></samp> option must be
+less than the interface MTU. Otherwise, the <samp><span class="option">-m</span></samp> and
+<samp><span class="option">-M</span></samp> options are just like their TCP/UDP/SCTP counterparts.
<p>Other DLPI-specific options include:
@@ -1627,7 +1661,7 @@
<br><dt><code>-s sap</code><dd>This option specifies the 802.2 SAP for the test. A SAP is somewhat
like either the port field of a TCP or UDP header or the protocol
field of an IP header. The specified SAP should not conflict with any
-other active SAPs on the specified PPA's (<span class="option">-p</span> option).
+other active SAPs on the specified PPA's (<samp><span class="option">-p</span></samp> option).
<br><dt><code>-w <sizespec></code><dd>This option specifies the local send and receive window sizes in units
of frames on those platforms which support setting such things.
<br><dt><code>-W <sizespec></code><dd>This option specifies the remote send and receive window sizes in
@@ -1640,10 +1674,12 @@
<div class="node">
<p><hr>
-<a name="DLCL_005fSTREAM"></a>Next: <a rel="next" accesskey="n" href="#STREAM_005fSTREAM">STREAM_STREAM</a>,
+<a name="DLCL_STREAM"></a>
+<a name="DLCL_005fSTREAM"></a>
+Next: <a rel="next" accesskey="n" href="#STREAM_005fSTREAM">STREAM_STREAM</a>,
Previous: <a rel="previous" accesskey="p" href="#DLCO_005fSTREAM">DLCO_STREAM</a>,
Up: <a rel="up" accesskey="u" href="#Options-common-to-TCP-UDP-and-SCTP-tests">Options common to TCP UDP and SCTP tests</a>
-<br>
+
</div>
<h4 class="subsection">5.2.9 DLCL_STREAM</h4>
@@ -1651,7 +1687,7 @@
<p>A DLPI ConnectionLess Stream (DLCL_STREAM) test is analogous to a
<a href="#UDP_005fSTREAM">UDP_STREAM</a> test in that both make use of unreliable/best-effort,
connection-less transports. The DLCL_STREAM test differs from the
-<a href="#UDP_005fSTREAM">UDP_STREAM</a> test in that the message size (<span class="option">-m</span> option) must
+<a href="#UDP_005fSTREAM">UDP_STREAM</a> test in that the message size (<samp><span class="option">-m</span></samp> option) must
always be less than the link MTU as there is no IP-like fragmentation
and reassembly available and netperf does not presume to provide one.
@@ -1664,10 +1700,12 @@
<div class="node">
<p><hr>
-<a name="STREAM_005fSTREAM"></a>Next: <a rel="next" accesskey="n" href="#DG_005fSTREAM">DG_STREAM</a>,
+<a name="STREAM_STREAM"></a>
+<a name="STREAM_005fSTREAM"></a>
+Next: <a rel="next" accesskey="n" href="#DG_005fSTREAM">DG_STREAM</a>,
Previous: <a rel="previous" accesskey="p" href="#DLCL_005fSTREAM">DLCL_STREAM</a>,
Up: <a rel="up" accesskey="u" href="#Options-common-to-TCP-UDP-and-SCTP-tests">Options common to TCP UDP and SCTP tests</a>
-<br>
+
</div>
<!-- node-name, next, previous, up -->
@@ -1676,9 +1714,9 @@
<p>A Unix Domain Stream Socket Stream test (STREAM_STREAM) is similar in
concept to a <a href="#TCP_005fSTREAM">TCP_STREAM</a> test, but using Unix Domain sockets. It is,
naturally, limited to intra-machine traffic. A STREAM_STREAM test
-shares the <span class="option">-m</span>, <span class="option">-M</span>, <span class="option">-s</span> and <span class="option">-S</span>
+shares the <samp><span class="option">-m</span></samp>, <samp><span class="option">-M</span></samp>, <samp><span class="option">-s</span></samp> and <samp><span class="option">-S</span></samp>
options of the other _STREAM tests. In a STREAM_STREAM test the
-<span class="option">-p</span> option sets the directory in which the pipes will be
+<samp><span class="option">-p</span></samp> option sets the directory in which the pipes will be
created rather than setting a port number. The default is to create
the pipes in the system default for the <code>tempnam()</code> call.
@@ -1688,9 +1726,11 @@
<div class="node">
<p><hr>
-<a name="DG_005fSTREAM"></a>Previous: <a rel="previous" accesskey="p" href="#STREAM_005fSTREAM">STREAM_STREAM</a>,
+<a name="DG_STREAM"></a>
+<a name="DG_005fSTREAM"></a>
+Previous: <a rel="previous" accesskey="p" href="#STREAM_005fSTREAM">STREAM_STREAM</a>,
Up: <a rel="up" accesskey="u" href="#Options-common-to-TCP-UDP-and-SCTP-tests">Options common to TCP UDP and SCTP tests</a>
-<br>
+
</div>
<!-- node-name, next, previous, up -->
@@ -1710,10 +1750,12 @@
<div class="node">
<p><hr>
-<a name="Using-Netperf-to-Measure-Request_002fResponse"></a>Next: <a rel="next" accesskey="n" href="#Other-Netperf-Tests">Other Netperf Tests</a>,
+<a name="Using-Netperf-to-Measure-Request%2fResponse"></a>
+<a name="Using-Netperf-to-Measure-Request_002fResponse"></a>
+Next: <a rel="next" accesskey="n" href="#Other-Netperf-Tests">Other Netperf Tests</a>,
Previous: <a rel="previous" accesskey="p" href="#Using-Netperf-to-Measure-Bulk-Data-Transfer">Using Netperf to Measure Bulk Data Transfer</a>,
Up: <a rel="up" accesskey="u" href="#Top">Top</a>
-<br>
+
</div>
<h2 class="chapter">6 Using Netperf to Measure Request/Response</h2>
@@ -1753,10 +1795,12 @@
<div class="node">
<p><hr>
-<a name="Issues-in-Request_002fResponse"></a>Next: <a rel="next" accesskey="n" href="#Options-Common-to-TCP-UDP-and-SCTP-_005fRR-tests">Options Common to TCP UDP and SCTP _RR tests</a>,
+<a name="Issues-in-Request%2fResponse"></a>
+<a name="Issues-in-Request_002fResponse"></a>
+Next: <a rel="next" accesskey="n" href="#Options-Common-to-TCP-UDP-and-SCTP-_005fRR-tests">Options Common to TCP UDP and SCTP _RR tests</a>,
Previous: <a rel="previous" accesskey="p" href="#Using-Netperf-to-Measure-Request_002fResponse">Using Netperf to Measure Request/Response</a>,
Up: <a rel="up" accesskey="u" href="#Using-Netperf-to-Measure-Request_002fResponse">Using Netperf to Measure Request/Response</a>
-<br>
+
</div>
<!-- node-name, next, previous, up -->
@@ -1793,9 +1837,11 @@
<div class="node">
<p><hr>
-<a name="Options-Common-to-TCP-UDP-and-SCTP-_005fRR-tests"></a>Previous: <a rel="previous" accesskey="p" href="#Issues-in-Request_002fResponse">Issues in Request/Response</a>,
+<a name="Options-Common-to-TCP-UDP-and-SCTP-_RR-tests"></a>
+<a name="Options-Common-to-TCP-UDP-and-SCTP-_005fRR-tests"></a>
+Previous: <a rel="previous" accesskey="p" href="#Issues-in-Request_002fResponse">Issues in Request/Response</a>,
Up: <a rel="up" accesskey="u" href="#Using-Netperf-to-Measure-Request_002fResponse">Using Netperf to Measure Request/Response</a>
-<br>
+
</div>
<!-- node-name, next, previous, up -->
@@ -1809,21 +1855,21 @@
<dl>
<dt><code>-h</code><dd>Display the test-suite-specific usage string and exit. For a TCP_ or
UDP_ test this will be the usage string from the source file
-<span class="file">nettest_bsd.c</span>. For an XTI_ test, this will be the usage string
-from the source file <span class="file">src/nettest_xti.c</span>. For an SCTP test, this
+<samp><span class="file">nettest_bsd.c</span></samp>. For an XTI_ test, this will be the usage string
+from the source file <samp><span class="file">src/nettest_xti.c</span></samp>. For an SCTP test, this
will be the usage string from the source file
-<span class="file">src/nettest_sctp.c</span>.
+<samp><span class="file">src/nettest_sctp.c</span></samp>.
<br><dt><code>-H <optionspec></code><dd>Normally, the remote hostname|IP and address family information is
inherited from the settings for the control connection (eg global
-command-line <span class="option">-H</span>, <span class="option">-4</span> and/or <span class="option">-6</span> options.
-The test-specific <span class="option">-H</span> will override those settings for the
+command-line <samp><span class="option">-H</span></samp>, <samp><span class="option">-4</span></samp> and/or <samp><span class="option">-6</span></samp> options.
+The test-specific <samp><span class="option">-H</span></samp> will override those settings for the
data (aka test) connection only. Settings for the control connection
are left unchanged. This might be used to cause the control and data
connections to take different paths through the network.
- <br><dt><code>-L <optionspec></code><dd>The test-specific <span class="option">-L</span> option is identical to the test-specific
-<span class="option">-H</span> option except it affects the local hostname|IP and address
+ <br><dt><code>-L <optionspec></code><dd>The test-specific <samp><span class="option">-L</span></samp> option is identical to the test-specific
+<samp><span class="option">-H</span></samp> option except it affects the local hostname|IP and address
family information. As with its global command-line counterpart, this
is generally only useful when measuring though those evil, end-to-end
breaking things called firewalls.
@@ -1879,11 +1925,11 @@
<br><dt><code>-4</code><dd>Set the local and remote address family for the data connection to
AF_INET - ie use IPv4 addressing only. Just as with their global
-command-line counterparts the last of the <span class="option">-4</span>, <span class="option">-6</span>,
-<span class="option">-H</span> or <span class="option">-L</span> option wins for their respective address
+command-line counterparts the last of the <samp><span class="option">-4</span></samp>, <samp><span class="option">-6</span></samp>,
+<samp><span class="option">-H</span></samp> or <samp><span class="option">-L</span></samp> option wins for their respective address
families.
- <br><dt><code>-6</code><dd>This option is identical to its <span class="option">-4</span> cousin, but requests IPv6
+ <br><dt><code>-6</code><dd>This option is identical to its <samp><span class="option">-4</span></samp> cousin, but requests IPv6
addresses for the local and remote ends of the data connection.
</dl>
@@ -1904,16 +1950,18 @@
<div class="node">
<p><hr>
-<a name="TCP_005fRR"></a>Next: <a rel="next" accesskey="n" href="#TCP_005fCC">TCP_CC</a>,
+<a name="TCP_RR"></a>
+<a name="TCP_005fRR"></a>
+Next: <a rel="next" accesskey="n" href="#TCP_005fCC">TCP_CC</a>,
Previous: <a rel="previous" accesskey="p" href="#Options-Common-to-TCP-UDP-and-SCTP-_005fRR-tests">Options Common to TCP UDP and SCTP _RR tests</a>,
Up: <a rel="up" accesskey="u" href="#Options-Common-to-TCP-UDP-and-SCTP-_005fRR-tests">Options Common to TCP UDP and SCTP _RR tests</a>
-<br>
+
</div>
<h4 class="subsection">6.2.1 TCP_RR</h4>
<p>A TCP_RR (TCP Request/Response) test is requested by passing a value
-of “TCP_RR” to the global <span class="option">-t</span> command-line option. A TCP_RR
+of “TCP_RR” to the global <samp><span class="option">-t</span></samp> command-line option. A TCP_RR
test can be though-of as a user-space to user-space <code>ping</code> with
no think time - it is a synchronous, one transaction at a time,
request/response test.
@@ -1932,7 +1980,7 @@
you want connection setup overheads included, you should consider the
TCP_CC or TCP_CRR tests.
- <p>If specifying the <span class="option">-D</span> option to set TCP_NODELAY and disable
+ <p>If specifying the <samp><span class="option">-D</span></samp> option to set TCP_NODELAY and disable
the Nagle Algorithm increases the transaction rate reported by a
TCP_RR test, it implies the stack(s) over which the TCP_RR test is
running have a broken implementation of the Nagle Algorithm. Likely
@@ -1959,16 +2007,18 @@
<div class="node">
<p><hr>
-<a name="TCP_005fCC"></a>Next: <a rel="next" accesskey="n" href="#TCP_005fCRR">TCP_CRR</a>,
+<a name="TCP_CC"></a>
+<a name="TCP_005fCC"></a>
+Next: <a rel="next" accesskey="n" href="#TCP_005fCRR">TCP_CRR</a>,
Previous: <a rel="previous" accesskey="p" href="#TCP_005fRR">TCP_RR</a>,
Up: <a rel="up" accesskey="u" href="#Options-Common-to-TCP-UDP-and-SCTP-_005fRR-tests">Options Common to TCP UDP and SCTP _RR tests</a>
-<br>
+
</div>
<h4 class="subsection">6.2.2 TCP_CC</h4>
<p>A TCP_CC (TCP Connect/Close) test is requested by passing a value of
-“TCP_CC” to the global <span class="option">-t</span> option. A TCP_CC test simply
+“TCP_CC” to the global <samp><span class="option">-t</span></samp> option. A TCP_CC test simply
measures how fast the pair of systems can open and close connections
between one another in a synchronous (one at a time) manner. While
this is considered an _RR test, no request or response is exchanged
@@ -1992,16 +2042,16 @@
from the range of 5000 to 65535. On systems with a 60 second
TIME_WAIT state, this should allow roughly 1000 transactions per
second. The size of the client port space used by netperf can be
-controlled via the test-specific <span class="option">-p</span> option, which takes a
+controlled via the test-specific <samp><span class="option">-p</span></samp> option, which takes a
<dfn>sizespec</dfn> as a value setting the minimum (first value) and
maximum (second value) port numbers used by netperf at the client end.
<p>Since no requests or responses are exchanged during a TCP_CC test,
-only the <span class="option">-H</span>, <span class="option">-L</span>, <span class="option">-4</span> and <span class="option">-6</span> of the
+only the <samp><span class="option">-H</span></samp>, <samp><span class="option">-L</span></samp>, <samp><span class="option">-4</span></samp> and <samp><span class="option">-6</span></samp> of the
“common” test-specific options are likely to have an effect, if any,
-on the results. The <span class="option">-s</span> and <span class="option">-S</span> options _may_ have
+on the results. The <samp><span class="option">-s</span></samp> and <samp><span class="option">-S</span></samp> options _may_ have
some effect if they alter the number and/or type of options carried in
-the TCP SYNchronize segments. The <span class="option">-P</span> and <span class="option">-r</span>
+the TCP SYNchronize segments. The <samp><span class="option">-P</span></samp> and <samp><span class="option">-r</span></samp>
options are utterly ignored.
<p>Since connection establishment and tear-down for TCP is not symmetric,
@@ -2010,16 +2060,18 @@
<div class="node">
<p><hr>
-<a name="TCP_005fCRR"></a>Next: <a rel="next" accesskey="n" href="#UDP_005fRR">UDP_RR</a>,
+<a name="TCP_CRR"></a>
+<a name="TCP_005fCRR"></a>
+Next: <a rel="next" accesskey="n" href="#UDP_005fRR">UDP_RR</a>,
Previous: <a rel="previous" accesskey="p" href="#TCP_005fCC">TCP_CC</a>,
Up: <a rel="up" accesskey="u" href="#Options-Common-to-TCP-UDP-and-SCTP-_005fRR-tests">Options Common to TCP UDP and SCTP _RR tests</a>
-<br>
+
</div>
<h4 class="subsection">6.2.3 TCP_CRR</h4>
<p>The TCP Connect/Request/Response (TCP_CRR) test is requested by
-passing a value of “TCP_CRR” to the global <span class="option">-t</span> command-line
+passing a value of “TCP_CRR” to the global <samp><span class="option">-t</span></samp> command-line
option. A TCP_RR test is like a merger of a TCP_RR and TCP_CC test
which measures the performance of establishing a connection, exchanging
a single request/response transaction, and tearing-down that
@@ -2027,8 +2079,8 @@
HTTP 1.1 connection when HTTP Keepalives are not used. In fact, the
TCP_CRR test was added to netperf to simulate just that.
- <p>Since a request and response are exchanged the <span class="option">-r</span>,
-<span class="option">-s</span> and <span class="option">-S</span> options can have an effect on the
+ <p>Since a request and response are exchanged the <samp><span class="option">-r</span></samp>,
+<samp><span class="option">-s</span></samp> and <samp><span class="option">-S</span></samp> options can have an effect on the
performance.
<p>The issue of TIME_WAIT reuse exists for the TCP_CRR test just as it
@@ -2038,16 +2090,18 @@
<div class="node">
<p><hr>
-<a name="UDP_005fRR"></a>Next: <a rel="next" accesskey="n" href="#XTI_005fTCP_005fRR">XTI_TCP_RR</a>,
+<a name="UDP_RR"></a>
+<a name="UDP_005fRR"></a>
+Next: <a rel="next" accesskey="n" href="#XTI_005fTCP_005fRR">XTI_TCP_RR</a>,
Previous: <a rel="previous" accesskey="p" href="#TCP_005fCRR">TCP_CRR</a>,
Up: <a rel="up" accesskey="u" href="#Options-Common-to-TCP-UDP-and-SCTP-_005fRR-tests">Options Common to TCP UDP and SCTP _RR tests</a>
-<br>
+
</div>
<h4 class="subsection">6.2.4 UDP_RR</h4>
<p>A UDP Request/Response (UDP_RR) test is requested by passing a value
-of “UDP_RR” to a global <span class="option">-t</span> option. It is very much the
+of “UDP_RR” to a global <samp><span class="option">-t</span></samp> option. It is very much the
same as a TCP_RR test except UDP is used rather than TCP.
<p>UDP does not provide for retransmission of lost UDP datagrams, and
@@ -2078,36 +2132,40 @@
65535 65535 1 1 10.01 15262.48 13.90 16.11 18.221 21.116
65535 65535
</pre>
- <p>This example includes the <span class="option">-c</span> and <span class="option">-C</span> options to
+ <p>This example includes the <samp><span class="option">-c</span></samp> and <samp><span class="option">-C</span></samp> options to
enable CPU utilization reporting and shows the asymmetry in CPU
-loading. The <span class="option">-T</span> option was used to make sure netperf and
+loading. The <samp><span class="option">-T</span></samp> option was used to make sure netperf and
netserver ran on a given CPU and did not move around during the test.
<div class="node">
<p><hr>
-<a name="XTI_005fTCP_005fRR"></a>Next: <a rel="next" accesskey="n" href="#XTI_005fTCP_005fCC">XTI_TCP_CC</a>,
+<a name="XTI_TCP_RR"></a>
+<a name="XTI_005fTCP_005fRR"></a>
+Next: <a rel="next" accesskey="n" href="#XTI_005fTCP_005fCC">XTI_TCP_CC</a>,
Previous: <a rel="previous" accesskey="p" href="#UDP_005fRR">UDP_RR</a>,
Up: <a rel="up" accesskey="u" href="#Options-Common-to-TCP-UDP-and-SCTP-_005fRR-tests">Options Common to TCP UDP and SCTP _RR tests</a>
-<br>
+
</div>
<h4 class="subsection">6.2.5 XTI_TCP_RR</h4>
<p>An XTI_TCP_RR test is essentially the same as a <a href="#TCP_005fRR">TCP_RR</a> test only
using the XTI rather than BSD Sockets interface. It is requested by
-passing a value of “XTI_TCP_RR” to the <span class="option">-t</span> global
+passing a value of “XTI_TCP_RR” to the <samp><span class="option">-t</span></samp> global
command-line option.
<p>The test-specific options for an XTI_TCP_RR test are the same as those
-for a TCP_RR test with the addition of the <span class="option">-X <devspec></span> option to
+for a TCP_RR test with the addition of the <samp><span class="option">-X <devspec></span></samp> option to
specify the names of the local and/or remote XTI device file(s).
<div class="node">
<p><hr>
-<a name="XTI_005fTCP_005fCC"></a>Next: <a rel="next" accesskey="n" href="#XTI_005fTCP_005fCRR">XTI_TCP_CRR</a>,
+<a name="XTI_TCP_CC"></a>
+<a name="XTI_005fTCP_005fCC"></a>
+Next: <a rel="next" accesskey="n" href="#XTI_005fTCP_005fCRR">XTI_TCP_CRR</a>,
Previous: <a rel="previous" accesskey="p" href="#XTI_005fTCP_005fRR">XTI_TCP_RR</a>,
Up: <a rel="up" accesskey="u" href="#Options-Common-to-TCP-UDP-and-SCTP-_005fRR-tests">Options Common to TCP UDP and SCTP _RR tests</a>
-<br>
+
</div>
<!-- node-name, next, previous, up -->
@@ -2115,10 +2173,12 @@
<div class="node">
<p><hr>
-<a name="XTI_005fTCP_005fCRR"></a>Next: <a rel="next" accesskey="n" href="#XTI_005fUDP_005fRR">XTI_UDP_RR</a>,
+<a name="XTI_TCP_CRR"></a>
+<a name="XTI_005fTCP_005fCRR"></a>
+Next: <a rel="next" accesskey="n" href="#XTI_005fUDP_005fRR">XTI_UDP_RR</a>,
Previous: <a rel="previous" accesskey="p" href="#XTI_005fTCP_005fCC">XTI_TCP_CC</a>,
Up: <a rel="up" accesskey="u" href="#Options-Common-to-TCP-UDP-and-SCTP-_005fRR-tests">Options Common to TCP UDP and SCTP _RR tests</a>
-<br>
+
</div>
<!-- node-name, next, previous, up -->
@@ -2126,30 +2186,34 @@
<div class="node">
<p><hr>
-<a name="XTI_005fUDP_005fRR"></a>Next: <a rel="next" accesskey="n" href="#DLCL_005fRR">DLCL_RR</a>,
+<a name="XTI_UDP_RR"></a>
+<a name="XTI_005fUDP_005fRR"></a>
+Next: <a rel="next" accesskey="n" href="#DLCL_005fRR">DLCL_RR</a>,
Previous: <a rel="previous" accesskey="p" href="#XTI_005fTCP_005fCRR">XTI_TCP_CRR</a>,
Up: <a rel="up" accesskey="u" href="#Options-Common-to-TCP-UDP-and-SCTP-_005fRR-tests">Options Common to TCP UDP and SCTP _RR tests</a>
-<br>
+
</div>
<h4 class="subsection">6.2.8 XTI_UDP_RR</h4>
<p>An XTI_UDP_RR test is essentially the same as a UDP_RR test only using
the XTI rather than BSD Sockets interface. It is requested by passing
-a value of “XTI_UDP_RR” to the <span class="option">-t</span> global command-line
+a value of “XTI_UDP_RR” to the <samp><span class="option">-t</span></samp> global command-line
option.
<p>The test-specific options for an XTI_UDP_RR test are the same as those
-for a UDP_RR test with the addition of the <span class="option">-X <devspec></span>
+for a UDP_RR test with the addition of the <samp><span class="option">-X <devspec></span></samp>
option to specify the name of the local and/or remote XTI device
file(s).
<div class="node">
<p><hr>
-<a name="DLCL_005fRR"></a>Next: <a rel="next" accesskey="n" href="#DLCO_005fRR">DLCO_RR</a>,
+<a name="DLCL_RR"></a>
+<a name="DLCL_005fRR"></a>
+Next: <a rel="next" accesskey="n" href="#DLCO_005fRR">DLCO_RR</a>,
Previous: <a rel="previous" accesskey="p" href="#XTI_005fUDP_005fRR">XTI_UDP_RR</a>,
Up: <a rel="up" accesskey="u" href="#Options-Common-to-TCP-UDP-and-SCTP-_005fRR-tests">Options Common to TCP UDP and SCTP _RR tests</a>
-<br>
+
</div>
<!-- node-name, next, previous, up -->
@@ -2157,10 +2221,12 @@
<div class="node">
<p><hr>
-<a name="DLCO_005fRR"></a>Next: <a rel="next" accesskey="n" href="#SCTP_005fRR">SCTP_RR</a>,
+<a name="DLCO_RR"></a>
+<a name="DLCO_005fRR"></a>
+Next: <a rel="next" accesskey="n" href="#SCTP_005fRR">SCTP_RR</a>,
Previous: <a rel="previous" accesskey="p" href="#DLCL_005fRR">DLCL_RR</a>,
Up: <a rel="up" accesskey="u" href="#Options-Common-to-TCP-UDP-and-SCTP-_005fRR-tests">Options Common to TCP UDP and SCTP _RR tests</a>
-<br>
+
</div>
<!-- node-name, next, previous, up -->
@@ -2168,9 +2234,11 @@
<div class="node">
<p><hr>
-<a name="SCTP_005fRR"></a>Previous: <a rel="previous" accesskey="p" href="#DLCO_005fRR">DLCO_RR</a>,
+<a name="SCTP_RR"></a>
+<a name="SCTP_005fRR"></a>
+Previous: <a rel="previous" accesskey="p" href="#DLCO_005fRR">DLCO_RR</a>,
Up: <a rel="up" accesskey="u" href="#Options-Common-to-TCP-UDP-and-SCTP-_005fRR-tests">Options Common to TCP UDP and SCTP _RR tests</a>
-<br>
+
</div>
<!-- node-name, next, previous, up -->
@@ -2178,10 +2246,11 @@
<div class="node">
<p><hr>
-<a name="Other-Netperf-Tests"></a>Next: <a rel="next" accesskey="n" href="#Address-Resolution">Address Resolution</a>,
+<a name="Other-Netperf-Tests"></a>
+Next: <a rel="next" accesskey="n" href="#Address-Resolution">Address Resolution</a>,
Previous: <a rel="previous" accesskey="p" href="#Using-Netperf-to-Measure-Request_002fResponse">Using Netperf to Measure Request/Response</a>,
Up: <a rel="up" accesskey="u" href="#Top">Top</a>
-<br>
+
</div>
<h2 class="chapter">7 Other Netperf Tests</h2>
@@ -2197,9 +2266,10 @@
<div class="node">
<p><hr>
-<a name="CPU-rate-calibration"></a>Previous: <a rel="previous" accesskey="p" href="#Other-Netperf-Tests">Other Netperf Tests</a>,
+<a name="CPU-rate-calibration"></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>
-<br>
+
</div>
<h3 class="section">7.1 CPU rate calibration</h3>
@@ -2217,8 +2287,8 @@
remote ystems, and if repeated for each netperf test would make taking
repeated measurements rather slow.
- <p>Thus, the netperf CPU utilization options <span class="option">-c</span> and and
-<span class="option">-C</span> can take an optional calibration value. This value is
+ <p>Thus, the netperf CPU utilization options <samp><span class="option">-c</span></samp> and and
+<samp><span class="option">-C</span></samp> can take an optional calibration value. This value is
used as the “idle rate” and the calibration step is not
performed. To determine the idle rate, netperf can be used to run
special tests which only report the value of the calibration - they
@@ -2247,18 +2317,19 @@
<div class="node">
<p><hr>
-<a name="Address-Resolution"></a>Next: <a rel="next" accesskey="n" href="#Enhancing-Netperf">Enhancing Netperf</a>,
+<a name="Address-Resolution"></a>
+Next: <a rel="next" accesskey="n" href="#Enhancing-Netperf">Enhancing Netperf</a>,
Previous: <a rel="previous" accesskey="p" href="#Other-Netperf-Tests">Other Netperf Tests</a>,
Up: <a rel="up" accesskey="u" href="#Top">Top</a>
-<br>
+
</div>
<!-- node-name, next, previous, up -->
<h2 class="chapter">8 Address Resolution</h2>
<p>Netperf versions 2.4.0 and later have merged IPv4 and IPv6 tests so
-the functionality of the tests in <span class="file">src/nettest_ipv6.c</span> has been
-subsumed into the tests in <span class="file">src/nettest_bsd.c</span> This has been
+the functionality of the tests in <samp><span class="file">src/nettest_ipv6.c</span></samp> has been
+subsumed into the tests in <samp><span class="file">src/nettest_bsd.c</span></samp> This has been
accomplished in part by switching from <code>gethostbyname()</code>to
<code>getaddrinfo()</code> exclusively. While it was theoretically possible
to get multiple results for a hostname from <code>gethostbyname()</code> it
@@ -2268,7 +2339,7 @@
<p>Now with <code>getaddrinfo</code> and particularly with AF_UNSPEC it is
increasingly likely that a given hostname will have multiple
associated addresses. The <code>establish_control()</code> routine of
-<span class="file">src/netlib.c</span> will indeed attempt to chose from among all the
+<samp><span class="file">src/netlib.c</span></samp> will indeed attempt to chose from among all the
matching IP addresses when establishing the control connection.
Netperf does not _really_ care if the control connection is IPv4 or
IPv6 or even mixed on either end.
@@ -2279,7 +2350,7 @@
<p>If you do run into problems with this, the easiest workaround is to
specify IP addresses for the data connection explicitly in the
-test-specific <span class="option">-H</span> and <span class="option">-L</span> options. At some point, the
+test-specific <samp><span class="option">-H</span></samp> and <samp><span class="option">-L</span></samp> options. At some point, the
netperf tests _may_ try to be more sophisticated in their parsing of
returns from <code>getaddrinfo()</code> - straw-man patches to
<a href="mailto:netperf-feedback at netperf.org">netperf-feedback at netperf.org</a> would of course be most welcome
@@ -2287,17 +2358,18 @@
<p>Netperf has leveraged code from other open-source projects with
amenable licensing to provide a replacement <code>getaddrinfo()</code> call
-on those platforms where the <span class="command">configure</span> script believes there
+on those platforms where the <samp><span class="command">configure</span></samp> script believes there
is no native getaddrinfo call. As of this writing, the replacement
<code>getaddrinfo()</code> as been tested on HP-UX 11.0 and then presumed to
run elsewhere.
<div class="node">
<p><hr>
-<a name="Enhancing-Netperf"></a>Next: <a rel="next" accesskey="n" href="#Index">Index</a>,
+<a name="Enhancing-Netperf"></a>
+Next: <a rel="next" accesskey="n" href="#Index">Index</a>,
Previous: <a rel="previous" accesskey="p" href="#Address-Resolution">Address Resolution</a>,
Up: <a rel="up" accesskey="u" href="#Top">Top</a>
-<br>
+
</div>
<!-- node-name, next, previous, up -->
@@ -2308,11 +2380,11 @@
“suite” of tests to netperf the general idea is to
<ol type=1 start=1>
-<li>Add files <span class="file">src/nettest_mumble.c</span> and <span class="file">src/nettest_mumble.h</span>
+<li>Add files <samp><span class="file">src/nettest_mumble.c</span></samp> and <samp><span class="file">src/nettest_mumble.h</span></samp>
where mumble is replaced with something meaningful for the test-suite.
-<li>Add support for an apropriate <span class="option">--enable-mumble</span> option in
-<span class="file">configure.ac</span>.
-<li>Edit <span class="file">src/netperf.c</span>, <span class="file">netsh.c</span>, and <span class="file">netserver.c</span> as
+<li>Add support for an apropriate <samp><span class="option">--enable-mumble</span></samp> option in
+<samp><span class="file">configure.ac</span></samp>.
+<li>Edit <samp><span class="file">src/netperf.c</span></samp>, <samp><span class="file">netsh.c</span></samp>, and <samp><span class="file">netserver.c</span></samp> as
required, using #ifdef WANT_MUMBLE.
<li>Compile and test
</ol>
@@ -2323,7 +2395,7 @@
describing the changes at a high level to
<a href="mailto:netperf-feedback at netperf.org">netperf-feedback at netperf.org</a> or perhaps
<a href="mailto:netperf-talk at netperf.org">netperf-talk at netperf.org</a>. If the concensus is positive, then
-sending context <span class="command">diff</span> results to
+sending context <samp><span class="command">diff</span></samp> results to
<a href="mailto:netperf-feedback at netperf.org">netperf-feedback at netperf.org</a> is the next step. From that
point, it is a matter of pestering the Netperf Contributing Editor
until he gets the changes incorporated :)
@@ -2334,9 +2406,10 @@
<div class="node">
<p><hr>
-<a name="Index"></a>Previous: <a rel="previous" accesskey="p" href="#Enhancing-Netperf">Enhancing Netperf</a>,
+<a name="Index"></a>
+Previous: <a rel="previous" accesskey="p" href="#Enhancing-Netperf">Enhancing Netperf</a>,
Up: <a rel="up" accesskey="u" href="#Top">Top</a>
-<br>
+
</div>
<h2 class="unnumbered">Index</h2>
Modified: trunk/doc/netperf4.pdf
===================================================================
--- trunk/doc/netperf4.pdf 2005-10-25 21:31:11 UTC (rev 4)
+++ trunk/doc/netperf4.pdf 2005-10-25 22:01:20 UTC (rev 5)
@@ -6857,7 +6857,7 @@
915 0 obj <<
/Producer (pdfTeX-1.10b)
/Creator (TeX)
-/CreationDate (D:20051019141900)
+/CreationDate (D:20051025145100)
>> endobj
xref
0 916
Modified: trunk/doc/netperf4.ps
===================================================================
--- trunk/doc/netperf4.ps 2005-10-25 21:31:11 UTC (rev 4)
+++ trunk/doc/netperf4.ps 2005-10-25 22:01:20 UTC (rev 5)
@@ -8,7 +8,7 @@
%DVIPSWebPage: (www.radicaleye.com)
%DVIPSCommandLine: dvips -o netperf4.ps netperf4.dvi
%DVIPSParameters: dpi=600, compressed
-%DVIPSSource: TeX output 2005.10.19:1419
+%DVIPSSource: TeX output 2005.10.25:1451
%%BeginProcSet: texc.pro
%!
/TeXDict 300 dict def TeXDict begin/N{def}def/B{bind def}N/S{exch}N/X{S
Modified: trunk/doc/netperf4.xml
===================================================================
--- trunk/doc/netperf4.xml 2005-10-25 21:31:11 UTC (rev 4)
+++ trunk/doc/netperf4.xml 2005-10-25 22:01:20 UTC (rev 5)
@@ -1,4 +1,5 @@
-<?xml version="1.0"?><!DOCTYPE texinfo PUBLIC "-//GNU//DTD TexinfoML V4.7//EN" "http://www.gnu.org/software/texinfo/dtd/4.7/texinfo.dtd">
+<?xml version="1.0"?>
+<!DOCTYPE texinfo PUBLIC "-//GNU//DTD TexinfoML V4.8//EN" "http://www.gnu.org/software/texinfo/dtd/4.8/texinfo.dtd">
<texinfo xml:lang="en">
<setfilename>netperf4.xml</setfilename>
<settitle>Care and Feeding of Netperf 4.X.X</settitle>
Modified: trunk/src/Makefile.am
===================================================================
--- trunk/src/Makefile.am 2005-10-25 21:31:11 UTC (rev 4)
+++ trunk/src/Makefile.am 2005-10-25 22:01:20 UTC (rev 5)
@@ -16,6 +16,11 @@
netperf_SOURCES = netperf.c $(COMMON_SRC)
netserver_SOURCES = netserver.c $(COMMON_SRC)
+# in theory this will cause these header files to be put in the
+# installed headers location, where folks who want to make their own
+# test libraries can find them
+include_HEADERS = netperf.h netconfidence.h
+
# in theory, the stuff below should deal with creating the requisite libs
lib_LTLIBRARIES = nettest_bsd.la netsysstats.la
Modified: trunk/src/Makefile.in
===================================================================
--- trunk/src/Makefile.in 2005-10-25 21:31:11 UTC (rev 4)
+++ trunk/src/Makefile.in 2005-10-25 22:01:20 UTC (rev 5)
@@ -155,6 +155,11 @@
netperf_SOURCES = netperf.c $(COMMON_SRC)
netserver_SOURCES = netserver.c $(COMMON_SRC)
+# in theory this will cause these header files to be put in the
+# installed headers location, where folks who want to make their own
+# test libraries can find them
+include_HEADERS = netperf.h netconfidence.h
+
# in theory, the stuff below should deal with creating the requisite libs
lib_LTLIBRARIES = nettest_bsd.la netsysstats.la
@@ -219,7 +224,9 @@
$(AM_LDFLAGS) $(LDFLAGS) -o $@
DIST_SOURCES = $(netsysstats_la_SOURCES) $(nettest_bsd_la_SOURCES) \
$(netperf_SOURCES) $(netserver_SOURCES)
-DIST_COMMON = $(srcdir)/Makefile.in Makefile.am \
+HEADERS = $(include_HEADERS)
+
+DIST_COMMON = $(include_HEADERS) $(srcdir)/Makefile.in Makefile.am \
missing/get_expiration_time.c missing/getaddrinfo.c \
missing/getopt.c missing/getopt1.c missing/inet_ntop.c
SOURCES = $(netsysstats_la_SOURCES) $(nettest_bsd_la_SOURCES) $(netperf_SOURCES) $(netserver_SOURCES)
@@ -363,7 +370,25 @@
distclean-libtool:
-rm -f libtool
uninstall-info-am:
+includeHEADERS_INSTALL = $(INSTALL_HEADER)
+install-includeHEADERS: $(include_HEADERS)
+ @$(NORMAL_INSTALL)
+ $(mkinstalldirs) $(DESTDIR)$(includedir)
+ @list='$(include_HEADERS)'; for p in $$list; do \
+ if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
+ f="`echo $$p | sed -e 's|^.*/||'`"; \
+ echo " $(includeHEADERS_INSTALL) $$d$$p $(DESTDIR)$(includedir)/$$f"; \
+ $(includeHEADERS_INSTALL) $$d$$p $(DESTDIR)$(includedir)/$$f; \
+ done
+uninstall-includeHEADERS:
+ @$(NORMAL_UNINSTALL)
+ @list='$(include_HEADERS)'; for p in $$list; do \
+ f="`echo $$p | sed -e 's|^.*/||'`"; \
+ echo " rm -f $(DESTDIR)$(includedir)/$$f"; \
+ rm -f $(DESTDIR)$(includedir)/$$f; \
+ done
+
ETAGS = etags
ETAGSFLAGS =
@@ -452,12 +477,12 @@
done
check-am: all-am
check: check-am
-all-am: Makefile $(LTLIBRARIES) $(PROGRAMS)
+all-am: Makefile $(LTLIBRARIES) $(PROGRAMS) $(HEADERS)
install-binPROGRAMS: install-libLTLIBRARIES
installdirs:
- $(mkinstalldirs) $(DESTDIR)$(libdir) $(DESTDIR)$(bindir)
+ $(mkinstalldirs) $(DESTDIR)$(libdir) $(DESTDIR)$(bindir) $(DESTDIR)$(includedir)
install: install-am
install-exec: install-exec-am
install-data: install-data-am
@@ -501,7 +526,7 @@
info-am:
-install-data-am:
+install-data-am: install-includeHEADERS
install-exec-am: install-binPROGRAMS install-libLTLIBRARIES
@@ -529,20 +554,21 @@
ps-am:
-uninstall-am: uninstall-binPROGRAMS uninstall-info-am \
- uninstall-libLTLIBRARIES
+uninstall-am: uninstall-binPROGRAMS uninstall-includeHEADERS \
+ uninstall-info-am uninstall-libLTLIBRARIES
.PHONY: CTAGS GTAGS all all-am check check-am clean clean-binPROGRAMS \
clean-generic clean-libLTLIBRARIES clean-libtool ctags \
distclean distclean-compile distclean-generic distclean-libtool \
distclean-tags distdir dvi dvi-am info info-am install \
install-am install-binPROGRAMS install-data install-data-am \
- install-exec install-exec-am install-info install-info-am \
- install-libLTLIBRARIES install-man install-strip installcheck \
- installcheck-am installdirs maintainer-clean \
- maintainer-clean-generic mostlyclean mostlyclean-compile \
- mostlyclean-generic mostlyclean-libtool pdf pdf-am ps ps-am \
- tags uninstall uninstall-am uninstall-binPROGRAMS \
+ install-exec install-exec-am install-includeHEADERS \
+ install-info install-info-am install-libLTLIBRARIES install-man \
+ install-strip installcheck installcheck-am installdirs \
+ maintainer-clean maintainer-clean-generic mostlyclean \
+ mostlyclean-compile mostlyclean-generic mostlyclean-libtool pdf \
+ pdf-am ps ps-am tags uninstall uninstall-am \
+ uninstall-binPROGRAMS uninstall-includeHEADERS \
uninstall-info-am uninstall-libLTLIBRARIES
Modified: trunk/src/netlib.c
===================================================================
--- trunk/src/netlib.c 2005-10-25 21:31:11 UTC (rev 4)
+++ trunk/src/netlib.c 2005-10-25 22:01:20 UTC (rev 5)
@@ -1229,7 +1229,7 @@
if ((doc = xmlNewDoc((xmlChar *)"1.0")) != NULL) {
/* zippity do dah */
doc->standalone = 0;
- dtd = xmlCreateIntSubset(doc,(xmlChar *)"message",NULL,DTD_FILE);
+ dtd = xmlCreateIntSubset(doc,(xmlChar *)"message",NULL,NETPERF_DTD_FILE);
if (dtd != NULL) {
if (((message_header = xmlNewNode(NULL,(xmlChar *)"message")) != NULL) &&
(xmlSetProp(message_header,(xmlChar *)"tonid",nid) != NULL) &&
Modified: trunk/src/netperf.h
===================================================================
--- trunk/src/netperf.h 2005-10-25 21:31:11 UTC (rev 4)
+++ trunk/src/netperf.h 2005-10-25 22:01:20 UTC (rev 5)
@@ -9,7 +9,7 @@
#include "netconfidence.h"
#define NETPERF_DEFAULT_SERVICE_NAME "netperf4"
-#define DTD_FILE (const xmlChar *)"./netperf_docs.dtd"
+#define NETPERF_DTD_FILE (const xmlChar *)"./netperf_docs.dtd"
#define NETPERF_VERSION (const xmlChar *)"4"
#define NETPERF_UPDATE (const xmlChar *)"0"
#define NETPERF_FIX (const xmlChar *)"999"
More information about the netperf-dev
mailing list