759 строки
41 KiB
HTML
759 строки
41 KiB
HTML
<HTML>
|
|
<HEAD>
|
|
<TITLE>Iperf version 2.0.0</TITLE>
|
|
<!-- $Id: index.html,v 1.1.1.1 2004/05/18 01:50:44 kgibbs Exp $ -->
|
|
</HEAD>
|
|
|
|
<BODY BGCOLOR="#FFFFFF" LINK="#006633" VLINK="#669900" ALINK="#669966">
|
|
|
|
<CENTER>
|
|
<P><IMG SRC="dast.gif"
|
|
ALT="Distributed Applications Support Team"></P>
|
|
</CENTER>
|
|
|
|
<H1>Iperf version 2.0.0</H1>
|
|
|
|
<H3>May 2004</H3>
|
|
|
|
<HR><!-- ----- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- -->
|
|
|
|
<H3>NLANR applications support
|
|
<BR><A HREF="http://dast.nlanr.net/">http://dast.nlanr.net/</A>
|
|
<BR><A HREF="mailto:dast@nlanr.net"><dast@nlanr.net></A>
|
|
</H3>
|
|
<P><FONT face="arial,helvetica">
|
|
<H1>Iperf User Docs</H1>
|
|
<H4>Mark Gates<br>
|
|
Ajay Tirumala<BR>
|
|
Jon Dugan<BR>
|
|
Kevin Gibbs<BR> </H4>
|
|
|
|
May 2004
|
|
<P></CENTER>
|
|
[<a href="#compiling">Compiling</A> |
|
|
<A href="#features">Features</A> |
|
|
<A href="#tuningtcp">Tuning a TCP connection</A> |
|
|
<A href="#tuningudp">Tuning a UDP connection</A> |
|
|
<A href="#multicast">Running multicast servers and clients</A> |
|
|
<A href="#ipv6">IPv6 Mode</A> |
|
|
<A href="#repmode">Representative Streams</A> |
|
|
<A href="#daemon"> Running Iperf as a daemon</A> |
|
|
<!--<A href="#adaptive">Adaptive Window Sizes</A> | -->
|
|
<A href="#service">Running Iperf as a Windows Service</A> ]
|
|
<HR>
|
|
<!-- ----- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- -->
|
|
<H2><A name=compiling></A>Compiling</H2>
|
|
|
|
Once you have the distribution, on UNIX,
|
|
unpack it using gzip and tar. That will create a new directory
|
|
'iperf-<version#>' with the source files and documentation.
|
|
<P>
|
|
|
|
Iperf compiles cleanly on many systems including Linux, SGI IRIX, HP-UX,
|
|
Solaris, AIX, and Cray UNICOS. Use '<TT>make</TT>' to configure for your OS and
|
|
compile the source code.
|
|
|
|
<BLOCKQUOTE><PRE>
|
|
|
|
gunzip -c iperf-<version>.tar.gz | tar -xvf -
|
|
cd iperf-<version>
|
|
./configure
|
|
make
|
|
|
|
</PRE></BLOCKQUOTE>
|
|
|
|
To install iperf, use '<TT>make install</TT>',
|
|
which will ask you where to install it. To recompile, the easiest way is to
|
|
start over. Do '<TT>make distclean</TT>' then '<TT>./configure; make</TT>'. See the Makefile
|
|
for more options.
|
|
<P>
|
|
|
|
If you have problems, please report them to <A href="mailto:dast@nlanr.net">dast@nlanr.net</A> and
|
|
we will try to fix them quickly. <BR>
|
|
|
|
<HR>
|
|
<!-- ----- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- -->
|
|
|
|
<H2><A name=features></A>Features</H2>
|
|
<UL>
|
|
<LI>TCP
|
|
<UL>
|
|
<LI>Measure bandwidth
|
|
<LI>Report MSS/MTU size and observed read sizes.
|
|
<LI>Support for TCP window size via socket buffers.
|
|
<LI>Multi-threaded if pthreads or Win32 threads are available. Client and
|
|
server can have multiple simultaneous connections.
|
|
<!-- <LI>Suggest the optimal window size for a connection where the OS allows
|
|
setting window sizes in the granularity of bytes. </LI>--></UL>
|
|
<LI>UDP
|
|
<UL>
|
|
<LI>Client can create UDP streams of specified bandwidth.
|
|
<LI>Measure packet loss
|
|
<LI>Measure delay jitter
|
|
<LI>Multicast capable
|
|
<LI>Multi-threaded if pthreads are available. Client and server can have
|
|
multiple simultaneous connections. (This doesn't work in Windows.) </LI></UL>
|
|
<LI>Where appropriate, options can be specified with K (kilo-) and M (mega-)
|
|
suffices. So 128K instead of 131072 bytes.
|
|
<LI>Can run for specified time, rather than a set amount of data to transfer.
|
|
<LI>Picks the best units for the size of data being reported.
|
|
<LI>Server handles multiple connections, rather than quitting after a single
|
|
test.
|
|
<LI>Print periodic, intermediate bandwidth, jitter, and loss reports at
|
|
specified intervals.
|
|
<LI>Run the server as a daemon (Check out <A
|
|
href="http://www-itg.lbl.gov/nettest">Nettest</A> for running it as a secure
|
|
daemon).
|
|
<LI>Run the server as a Windows NT Service
|
|
<LI>Use representative streams to test out how link layer compression affects
|
|
your achievable bandwidth.
|
|
|
|
<!-- <LI>A library of <A
|
|
href="lib.html">useful functions and C++
|
|
classes.</A> </LI>
|
|
-->
|
|
</UL>
|
|
<HR>
|
|
<!-- ----- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- --><BR>
|
|
|
|
<TABLE cellPadding=3 border=1>
|
|
<TBODY>
|
|
<TR vAlign=top>
|
|
<TH align=left>Command line option</TH>
|
|
<TH align=left>Environment variable option</TH>
|
|
<TH align=left>Description</TH></TR>
|
|
<TR>
|
|
<TH bgColor=#cccccc colSpan=3>Client and Server options</TH></TR>
|
|
<TR vAlign=top>
|
|
<TD><A name=format></A><TT>-f, --format <I>[bkmaBKMA]</I></TT></TD>
|
|
<TD><TT>$IPERF_FORMAT</TT></TD>
|
|
<TD>A letter specifying the format to print bandwidth numbers in.
|
|
Supported formats are
|
|
<PRE>
|
|
'b' = bits/sec 'B' = Bytes/sec
|
|
'k' = Kbits/sec 'K' = KBytes/sec
|
|
'm' = Mbits/sec 'M' = MBytes/sec
|
|
'g' = Gbits/sec 'G' = GBytes/sec
|
|
'a' = adaptive bits/sec 'A' = adaptive Bytes/sec
|
|
</PRE>
|
|
The adaptive formats choose between kilo- and mega- as appropriate. Fields
|
|
other than bandwidth always print bytes, but otherwise follow the
|
|
requested format. Default is 'a'. <BR><I>NOTE:</I> here Kilo = 1024,
|
|
Mega = 1024^2 and Giga = 1024^3 when dealing with bytes. Commonly in networking,
|
|
Kilo = 1000, Mega = 1000^2, and Giga = 1000^3 so we use this when dealing with
|
|
bits. If this really bothers you, use -f b and do the math.</TD></TR>
|
|
<TR vAlign=top>
|
|
<TD><A name=interval></A><TT>-i, --interval <I>#</I></TT></TD>
|
|
<TD><TT>$IPERF_INTERVAL</TT></TD>
|
|
<TD>Sets the interval time in seconds between periodic bandwidth, jitter,
|
|
and loss reports. If non-zero, a report is made every <I>interval</I>
|
|
seconds of the bandwidth since the last report. If zero, no periodic
|
|
reports are printed. Default is zero.</TD></TR>
|
|
<TR vAlign=top>
|
|
<TD><A name=len></A><TT>-l, --len <I>#[KM]</I></TT></TD>
|
|
<TD><TT>$IPERF_LEN</TT></TD>
|
|
<TD>The length of buffers to read or write. Iperf works by writing an
|
|
array of <I>len</I> bytes a number of times. Default is 8 KB for TCP, 1470
|
|
bytes for UDP. Note for UDP, this is the datagram size and needs to be lowered when using
|
|
IPv6 addressing to 1450 or less to avoid fragmentation. See also the <A
|
|
href="#num">-n</A>
|
|
and <A
|
|
href="#time">-t</A>
|
|
options.</TD></TR>
|
|
<TR vAlign=top>
|
|
<TD><A name=print_mss></A><TT>-m, --print_mss</TT></TD>
|
|
<TD><TT>$IPERF_PRINT_MSS</TT></TD>
|
|
<TD>Print the reported TCP MSS size (via the TCP_MAXSEG option) and the
|
|
observed read sizes which often correlate with the MSS. The MSS is usually
|
|
the MTU - 40 bytes for the TCP/IP header. Often a slightly smaller MSS is
|
|
reported because of extra header space from IP options. The interface type
|
|
corresponding to the MTU is also printed (ethernet, FDDI, etc.). This
|
|
option is not implemented on many OSes, but the read sizes may still
|
|
indicate the MSS.</TD></TR>
|
|
<TR vAlign=top>
|
|
<TD><A name=port></A><TT>-p, --port <I>#</I></TT></TD>
|
|
<TD><TT>$IPERF_PORT</TT></TD>
|
|
<TD>The server port for the server to listen on and the client to connect
|
|
to. This should be the same in both client and server. Default is 5001,
|
|
the same as ttcp.</TD></TR>
|
|
<TR vAlign=top>
|
|
<TD><A name=udp></A><TT>-u, --udp</TT></TD>
|
|
<TD><TT>$IPERF_UDP</TT></TD>
|
|
<TD>Use UDP rather than TCP. See also the <A
|
|
href="#bandwidth">-b</A>
|
|
option.</TD></TR>
|
|
<TR vAlign=top>
|
|
<TD><A name=window></A><TT>-w, --window <I>#[KM]</I></TT></TD>
|
|
<TD><TT>$TCP_WINDOW_SIZE</TT></TD>
|
|
<TD>Sets the socket buffer sizes to the specified value. For TCP, this
|
|
sets the TCP window size. For UDP it is just the buffer which datagrams
|
|
are received in, and so limits the largest receivable datagram size.</TD></TR>
|
|
<TR vAlign=top>
|
|
<TD><A name=bind></A><TT>-B, --bind <I>host</I></TT></TD>
|
|
<TD><TT>$IPERF_BIND</TT></TD>
|
|
<TD>Bind to <I>host</I>, one of this machine's addresses. For the client
|
|
this sets the outbound interface. For a server this sets the incoming
|
|
interface. This is only useful on multihomed hosts, which have multiple
|
|
network interfaces.
|
|
<P>For Iperf in UDP server mode, this is also used to bind and join to a
|
|
multicast group. Use addresses in the range 224.0.0.0 to 239.255.255.255
|
|
for multicast. See also the <A
|
|
href="#ttl">-T</A>
|
|
option.</P></TD></TR>
|
|
<TR vAlign=top>
|
|
<TD><A name=compatibility></A><TT>-C, --compatibility </TT></TD>
|
|
<TD><TT>$IPERF_COMPAT</TT></TD>
|
|
<TD>Compatibility mode allows for use with older version of iperf. This mode
|
|
is not required for interoperability but it is highly recommended. In
|
|
some cases when using representative streaming you could cause a 1.7 server
|
|
to crash or cause undesired connection attempts.</P></TD></TR>
|
|
<TR vAlign=top>
|
|
<TD><A name=mss></A><TT>-M, --mss <I>#[KM}</I></TT></TD>
|
|
<TD><TT>$IPERF_MSS</TT></TD>
|
|
<TD>Attempt to set the TCP maximum segment size (MSS) via the TCP_MAXSEG
|
|
option. The MSS is usually the MTU - 40 bytes for the TCP/IP header. For
|
|
ethernet, the MSS is 1460 bytes (1500 byte MTU). This option is not
|
|
implemented on many OSes.</TD></TR>
|
|
<TR vAlign=top>
|
|
<TD><A name=nodelay></A><TT>-N, --nodelay</TT></TD>
|
|
<TD><TT>$IPERF_NODELAY</TT></TD>
|
|
<TD>Set the TCP no delay option, disabling Nagle's algorithm. Normally
|
|
this is only disabled for interactive applications like telnet.</TD></TR>
|
|
<TR>
|
|
<TD><TT>-V </TT>(from v1.6 or higher)</TD>
|
|
<TD>.</TD>
|
|
<TD>Bind to an IPv6 address <BR>Server side: <BR>$ iperf -s -V
|
|
<P>Client side: <BR>$ iperf -c <Server IPv6 Address> -V
|
|
<BR> </P>Note: On version 1.6.3 and later a specific IPv6 Address does
|
|
not need to be bound with the <A href="#bind">-B</A> option, previous 1.6
|
|
versions do. Also on most OSes using this option will also respond to IPv4
|
|
clients using IPv4 mapped addresses.</TD></TR>
|
|
<TR>
|
|
<TH bgColor=#cccccc colSpan=3>Server specific options</TH></TR>
|
|
<TR vAlign=top>
|
|
<TD><A name=server></A><TT>-s, --server</TT></TD>
|
|
<TD><TT>$IPERF_SERVER</TT></TD>
|
|
<TD>Run Iperf in server mode.</TD></TR>
|
|
<TR>
|
|
<TD><TT>-D </TT> (from v1.2 or higher)</TD>
|
|
<TD>.</TD>
|
|
<TD>Run the server as a daemon (Unix platforms) <BR>On Win32 platforms
|
|
where services are available, Iperf will start running as a service.</TD></TR>
|
|
<TR>
|
|
<TD><TT>-R </TT>(only for Windows, from v1.2 or higher)</TD>
|
|
<TD>.</TD>
|
|
<TD>Remove the Iperf service (if it's running). </TD></TR><TR>
|
|
<TD><TT>-o </TT>(only for Windows, from v1.2 or higher)</TD>
|
|
<TD>.</TD>
|
|
<TD>Redirect output to given file. </TD></TR>
|
|
<TR vAlign=top>
|
|
<TD><A name=sclient></A><TT>-c, --client <I>host</I></TT></TD>
|
|
<TD><TT>$IPERF_CLIENT</TT></TD>
|
|
<TD> If Iperf is in server mode, then specifying a host with -c
|
|
will limit the connections that Iperf will accept to the
|
|
<I>host</I> specified. Does not work well for UDP.</TD></TR>
|
|
<TR vAlign=top>
|
|
<TD><A name=sparallel></A><TT>-P, --parallel <I>#</I></TT></TD>
|
|
<TD><TT>$IPERF_PARALLEL</TT></TD>
|
|
<TD>The number of connections to handle by the server before
|
|
closing. Default is 0 (which means to accept connections forever).</TD></TR>
|
|
<TR>
|
|
<TH bgColor=#cccccc colSpan=3>Client specific options</TH></TR>
|
|
<TR vAlign=top>
|
|
<TD><A name=bandwidth></A><TT>-b, --bandwidth <I>#[KM]</I></TT></TD>
|
|
<TD><TT>$IPERF_BANDWIDTH</TT></TD>
|
|
<TD>The UDP bandwidth to send at, in bits/sec. This implies the -u option.
|
|
Default is 1 Mbit/sec.</TD></TR>
|
|
<TR vAlign=top>
|
|
<TD><A name=client></A><TT>-c, --client <I>host</I></TT></TD>
|
|
<TD><TT>$IPERF_CLIENT</TT></TD>
|
|
<TD>Run Iperf in client mode, connecting to an Iperf server running on
|
|
<I>host</I>.</TD></TR>
|
|
<TR vAlign=top>
|
|
<TD><A name=dualtest></A><TT>-d, --dualtest </TT></TD>
|
|
<TD><TT>$IPERF_DUALTEST</TT></TD>
|
|
<TD>Run Iperf in dual testing mode. This will cause the server to connect
|
|
back to the client on the port specified in the
|
|
<A href="#listenport">-L</A> option (or defaults
|
|
to the port the client connected to the server on). This is done immediately
|
|
therefore running the tests simultaneously. If you want an alternating
|
|
test try <A href="#tradeoff">-r.</A></TD></TR>
|
|
<TR vAlign=top>
|
|
<TD><A name=num></A><TT>-n, --num <I>#[KM]</I></TT></TD>
|
|
<TD><TT>$IPERF_NUM</TT></TD>
|
|
<TD>The number of buffers to transmit. Normally, Iperf sends for 10
|
|
seconds. The -n option overrides this and sends an array of <I>len</I>
|
|
bytes <I>num</I> times, no matter how long that takes. See also the <A
|
|
href="#len">-l</A>
|
|
and <A
|
|
href="#time">-t</A>
|
|
options.</TD></TR>
|
|
<TR vAlign=top>
|
|
<TD><A name=tradeoff></A><TT>-r, --tradeoff </TT></TD>
|
|
<TD><TT>$IPERF_TRADEOFF</TT></TD>
|
|
<TD>Run Iperf in tradeoff testing mode. This will cause the server to connect
|
|
back to the client on the port specified in the
|
|
<A href="#listenport">-L</A> option (or defaults
|
|
to the port the client connected to the server on). This is done following
|
|
the client connection termination, therefore running the tests
|
|
alternating. If you want an simultaneous test try
|
|
<A href="#dualtest">-d.</A></TD></TR>
|
|
<TR vAlign=top>
|
|
<TD><A name=time></A><TT>-t, --time <I>#</I></TT></TD>
|
|
<TD><TT>$IPERF_TIME</TT></TD>
|
|
<TD>The time in seconds to transmit for. Iperf normally works by
|
|
repeatedly sending an array of <I>len</I> bytes for <I>time</I> seconds.
|
|
Default is 10 seconds. See also the <A
|
|
href="#len">-l</A>
|
|
and <A
|
|
href="#num">-n</A>
|
|
options.</TD></TR>
|
|
<TR vAlign=top>
|
|
<TD><A name=listenport></A><TT>-L, --listenport <I>#</I></TT></TD>
|
|
<TD><TT>$IPERF_LISTENPORT</TT></TD>
|
|
<TD>This specifies the port that the server will connect back to the
|
|
client on. It defaults to the port used to connect to the server
|
|
from the client.</TD></TR>
|
|
<TR vAlign=top>
|
|
<TD><A name=parallel></A><TT>-P, --parallel <I>#</I></TT></TD>
|
|
<TD><TT>$IPERF_PARALLEL</TT></TD>
|
|
<TD>The number of simultaneous connections to make to the server. Default
|
|
is 1. Requires thread support on both the client and server.</TD></TR>
|
|
<TR vAlign=top>
|
|
<TD><A name=tos></A><TT>-S, --tos <I>#</I></TT></TD>
|
|
<TD><TT>$IPERF_TOS</TT></TD>
|
|
<TD>The type-of-service for outgoing packets. (Many routers ignore the TOS
|
|
field.) You may specify the value in hex with a '0x' prefix, in octal with
|
|
a '0' prefix, or in decimal. For example, '0x10' hex = '020' octal = '16'
|
|
decimal. The TOS numbers specified in RFC 1349 are:
|
|
<PRE>
|
|
IPTOS_LOWDELAY minimize delay 0x10
|
|
IPTOS_THROUGHPUT maximize throughput 0x08
|
|
IPTOS_RELIABILITY maximize reliability 0x04
|
|
IPTOS_LOWCOST minimize cost 0x02
|
|
|
|
</PRE>
|
|
</TD></TR>
|
|
<TR vAlign=top>
|
|
<TD><A name=ttl></A><TT>-T, --ttl <I>#</I></TT></TD>
|
|
<TD><TT>$IPERF_TTL</TT></TD>
|
|
<TD>The time-to-live for outgoing multicast packets. This is essentially
|
|
the number of router hops to go through, and is also used for scoping.
|
|
Default is 1, link-local.</TD></TR>
|
|
<TR>
|
|
<TD><TT>-F</TT> (from v1.2 or higher)</TD>
|
|
<TD>.</TD>
|
|
<TD>Use a representative stream to measure bandwidth, e.g. :- <BR>$
|
|
iperf -c <server address> -F <file-name></TD></TR>
|
|
<TR>
|
|
<TD><TT>-I </TT>(from v1.2 or higher)</TD>
|
|
<TD>.</TD>
|
|
<TD>Same as -F, input from stdin.</TD></TR>
|
|
<!-- <TR>
|
|
<TD><TT>-W </TT>(from v1.2 or higher)</TD>
|
|
<TD>.</TD>
|
|
<TD>Adaptive Window Sizes.
|
|
<BR>Use Iperf to suggest the best Window size for a connection. Iperf will start from a default window size and try to perform a search for the optimal window size</TD></TR>
|
|
--> <TR>
|
|
<TH bgColor=#cccccc colSpan=3>Miscellaneous options</TH></TR>
|
|
<TR vAlign=top>
|
|
<TD><A name=help></A><TT>-h, --help</TT></TD>
|
|
<TD> </TD>
|
|
<TD>Print out a summary of commands and quit.</TD></TR>
|
|
<TR vAlign=top>
|
|
<TD><A name=version></A><TT>-v, --version</TT></TD>
|
|
<TD> </TD>
|
|
<TD>Print version information and quit. Prints 'pthreads' if compiled with
|
|
POSIX threads, 'win32 threads' if compiled with Microsoft Win32 threads,
|
|
or 'single threaded' if compiled without threads.</TD></TR></TBODY></TABLE>
|
|
<P>
|
|
<HR>
|
|
<!-- ----- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- -->
|
|
<H2><A name=tuningtcp></A>Tuning a TCP connection</H2>
|
|
|
|
The primary goal of Iperf
|
|
is to help in tuning TCP connections over a particular path. The most
|
|
fundamental tuning issue for TCP is the TCP window size, which controls how much
|
|
data can be in the network at any one point. If it is too small, the sender will
|
|
be idle at times and get poor performance. The theoretical value to use for the
|
|
TCP window size is the <I>bandwidth delay product</I>,
|
|
<BLOCKQUOTE>bottleneck bandwidth * round trip time</BLOCKQUOTE>In the below
|
|
modi4/cyclops example, the bottleneck link is a 45 Mbit/sec DS3 link and the
|
|
round trip time measured with ping is 42 ms. The bandwidth delay product is
|
|
<BLOCKQUOTE>45 Mbit/sec * 42 ms <BR>= (45e6) * (42e-3) <BR>= 1890000 bits
|
|
<BR>= 230 KByte</BLOCKQUOTE>That is a starting point for figuring the best
|
|
window size; setting it higher or lower may produce better results. In our
|
|
example, buffer sizes over 130K did not improve the performance, despite the
|
|
bandwidth delay product of 230K.
|
|
<P>Note that many OSes and hosts have upper limits on the TCP window size. These
|
|
may be as low as 64 KB, or as high as several MB. Iperf tries to detect when
|
|
these occur and give a warning that the actual and requested window sizes are
|
|
not equal (as below, though that is due to rounding in IRIX). PSC has a <A
|
|
href="http://www.psc.edu/networking/perf_tune.html">list detailing</A> how to
|
|
change the default and maximum window sizes for various OSes. For more
|
|
information on TCP window sizes, see the <A
|
|
href="http://dast.nlanr.net/Guides/GettingStarted/TCP_window_size.html">User's
|
|
Guide to TCP Windows.</A>
|
|
<P>Here is an example session, between node1 in Illinois and node2 in North
|
|
Carolina. These are connected via the vBNS backbone and a 45 Mbit/sec DS3 link.
|
|
Notice we improve bandwidth performance by a factor of 3 using proper TCP window
|
|
sizes. Use the adaptive window sizes feature on platforms which allow setting
|
|
window sizes in the granularity of bytes.
|
|
<BLOCKQUOTE>
|
|
<PRE>
|
|
<B>node2></B> iperf -s
|
|
------------------------------------------------------------
|
|
Server listening on TCP port 5001
|
|
TCP window size: 60.0 KByte (default)
|
|
------------------------------------------------------------
|
|
[ 4] local <IP Addr node2> port 5001 connected with <IP Addr node1> port 2357
|
|
[ ID] Interval Transfer Bandwidth
|
|
[ 4] 0.0-10.1 sec 6.5 MBytes <B><FONT color=#ff0000>5.2 Mbits/sec
|
|
|
|
</FONT>node1></B> iperf -c node2
|
|
------------------------------------------------------------
|
|
Client connecting to node1, TCP port 5001
|
|
TCP window size: 59.9 KByte (default)
|
|
------------------------------------------------------------
|
|
[ 3] local <IP Addr node1> port 2357 connected with <IP Addr node2> port 5001
|
|
[ ID] Interval Transfer Bandwidth
|
|
[ 3] 0.0-10.0 sec 6.5 MBytes 5.2 Mbits/sec</PRE>
|
|
<HR>
|
|
<PRE><B>node2></B> iperf -s -w 130k
|
|
------------------------------------------------------------
|
|
Server listening on TCP port 5001
|
|
TCP window size: 130 KByte
|
|
------------------------------------------------------------
|
|
[ 4] local <IP Addr node 2> port 5001 connected with <IP Addr node 1> port 2530
|
|
[ ID] Interval Transfer Bandwidth
|
|
[ 4] 0.0-10.1 sec 19.7 MBytes <B><FONT color=#ff0000>15.7 Mbits/sec
|
|
|
|
</FONT>node1></B> iperf -c node2 -w 130k
|
|
------------------------------------------------------------
|
|
Client connecting to node2, TCP port 5001
|
|
TCP window size: 129 KByte (WARNING: requested 130 KByte)
|
|
------------------------------------------------------------
|
|
[ 3] local <IP Addr node1> port 2530 connected with <IP Addr node2> port 5001
|
|
[ ID] Interval Transfer Bandwidth
|
|
[ 3] 0.0-10.0 sec 19.7 MBytes 15.8 Mbits/sec</PRE></BLOCKQUOTE>Another
|
|
test to do is run parallel TCP streams. If the total aggregate bandwidth is more
|
|
than what an individual stream gets, something is wrong. Either the TCP window
|
|
size is too small, or the OS's TCP implementation has bugs, or the network
|
|
itself has deficiencies. See above for TCP window sizes; otherwise diagnosing
|
|
which is somewhat difficult. If Iperf is compiled with pthreads, a single client
|
|
and server can test this, otherwise setup multiple clients and servers on
|
|
different ports. Here's an example where a single stream gets 16.5 Mbit/sec, but
|
|
two parallel streams together get 16.7 + 9.4 = 26.1 Mbit/sec, even when using
|
|
large TCP window sizes:
|
|
<BLOCKQUOTE><PRE><B>node2></B> iperf -s -w 300k
|
|
------------------------------------------------------------
|
|
Server listening on TCP port 5001
|
|
TCP window size: 300 KByte
|
|
------------------------------------------------------------
|
|
[ 4] local <IP Addr node2> port 5001 connected with <IP Addr node1> port 6902
|
|
[ ID] Interval Transfer Bandwidth
|
|
[ 4] 0.0-10.2 sec 20.9 MBytes <B><FONT color=#ff0000>16.5 Mbits/sec
|
|
|
|
</FONT></B>[ 4] local <IP Addr node2> port 5001 connected with <IP Addr node1> port 6911
|
|
[ 5] local <IP Addr node2> port 5001 connected with <IP Addr node2> port 6912
|
|
[ ID] Interval Transfer Bandwidth
|
|
[ 5] 0.0-10.1 sec 21.0 MBytes <B><FONT color=#ff0000>16.7 Mbits/sec
|
|
</FONT></B>[ 4] 0.0-10.3 sec 12.0 MBytes <B><FONT color=#ff0000> 9.4 Mbits/sec
|
|
|
|
</FONT>node1></B> ./iperf -c node2 -w 300k
|
|
------------------------------------------------------------
|
|
Client connecting to node2, TCP port 5001
|
|
TCP window size: 299 KByte (WARNING: requested 300 KByte)
|
|
------------------------------------------------------------
|
|
[ 3] local <IP Addr node2> port 6902 connected with <IP Addr node1> port 5001
|
|
[ ID] Interval Transfer Bandwidth
|
|
[ 3] 0.0-10.2 sec 20.9 MBytes 16.4 Mbits/sec
|
|
|
|
<B>node1></B> iperf -c node2 -w 300k -P 2
|
|
------------------------------------------------------------
|
|
Client connecting to node2, TCP port 5001
|
|
TCP window size: 299 KByte (WARNING: requested 300 KByte)
|
|
------------------------------------------------------------
|
|
[ 4] local <IP Addr node2> port 6912 connected with <IP Addr node1> port 5001
|
|
[ 3] local <IP Addr node2> port 6911 connected with <IP Addr node1> port 5001
|
|
[ ID] Interval Transfer Bandwidth
|
|
[ 4] 0.0-10.1 sec 21.0 MBytes 16.6 Mbits/sec
|
|
[ 3] 0.0-10.2 sec 12.0 MBytes 9.4 Mbits/sec</PRE></BLOCKQUOTE>A
|
|
secondary tuning issue for TCP is the maximum transmission unit (MTU). To be
|
|
most effective, both hosts should support Path MTU Discovery. PSC has a <A
|
|
href="http://www.psc.edu/networking/perf_tune.html">list detailing</A> what OSes
|
|
support Path MTU Discovery. Hosts without Path MTU Discovery often use 536 as
|
|
the MSS, which wastes bandwidth and processing time. Use the -m option to
|
|
display what MSS is being used, and see if this matches what you expect. Often
|
|
it is around 1460 bytes for ethernet.
|
|
<BLOCKQUOTE><PRE><B>node3></B> iperf -s -m
|
|
------------------------------------------------------------
|
|
Server listening on TCP port 5001
|
|
TCP window size: 60.0 KByte (default)
|
|
------------------------------------------------------------
|
|
[ 4] local <IP Addr node3> port 5001 connected with <IP Addr node4> port 1096
|
|
[ ID] Interval Transfer Bandwidth
|
|
[ 4] 0.0- 2.0 sec 1.8 MBytes 6.9 Mbits/sec
|
|
[ 4] <B><FONT color=#ff0000>MSS size 1448 bytes (MTU 1500 bytes, ethernet)
|
|
</FONT></B>[ 4] Read lengths occurring in more than 5% of reads:
|
|
[ 4] 952 bytes read 219 times (16.2%)
|
|
[ 4] 1448 bytes read 1128 times (83.6%)</PRE></BLOCKQUOTE>Here
|
|
is a host that doesn't support Path MTU Discovery. It will only send and receive
|
|
small 576 byte packets.
|
|
<BLOCKQUOTE><PRE><B>node4></B> iperf -s -m
|
|
------------------------------------------------------------
|
|
Server listening on TCP port 5001
|
|
TCP window size: 32.0 KByte (default)
|
|
------------------------------------------------------------
|
|
[ 4] local <IP Addr node4> port 5001 connected with <IP Addr node3> port 13914
|
|
[ ID] Interval Transfer Bandwidth
|
|
[ 4] 0.0- 2.3 sec 632 KBytes 2.1 Mbits/sec
|
|
<B><FONT color=#ff0000>WARNING: Path MTU Discovery may not be enabled.
|
|
</FONT></B>[ 4] <B><FONT color=#ff0000>MSS size 536 bytes (MTU 576 bytes, minimum)
|
|
</FONT></B>[ 4] Read lengths occurring in more than 5% of reads:
|
|
[ 4] 536 bytes read 308 times (58.4%)
|
|
[ 4] 1072 bytes read 91 times (17.3%)
|
|
[ 4] 1608 bytes read 29 times (5.5%)</PRE></BLOCKQUOTE>Iperf
|
|
supports other tuning options, which were added for exceptional network
|
|
situations like HIPPI-to-HIPPI over ATM. <BR>
|
|
<HR>
|
|
<!-- ----- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- -->
|
|
|
|
<H2><A name=tuningudp></A>Tuning a UDP connection</H2>
|
|
|
|
Iperf creates a constant bit rate UDP stream. This is a very artificial
|
|
stream, similar to voice communication but not much else.
|
|
<P>
|
|
|
|
You will want to adjust the datagram size (-l) to the size your application
|
|
uses.
|
|
<P>
|
|
|
|
The server detects UDP datagram loss by ID numbers in the datagrams. Usually
|
|
a UDP datagram becomes several IP packets. Losing a single IP packet will lose
|
|
the entire datagram. To measure packet loss instead of datagram loss, make the
|
|
datagrams small enough to fit into a single packet, using the -l option. The
|
|
default size of 1470 bytes works for ethernet. Out-of-order packets are also
|
|
detected. (Out-of-order packets cause some ambiguity in the lost packet count;
|
|
Iperf assumes they are not duplicate packets, so they are excluded from the lost
|
|
packet count.) Since TCP does not report loss to the user, I find UDP tests
|
|
helpful to see packet loss along a path.
|
|
<P>
|
|
|
|
Jitter calculations are continuously computed by the server, as specified by
|
|
RTP in RFC 1889. The client records a 64 bit second/microsecond timestamp in the
|
|
packet. The server computes the relative transit time as (server's receive time
|
|
- client's send time). The client's and server's clocks do not need to be
|
|
synchronized; any difference is subtracted out in the jitter calculation. Jitter
|
|
is the smoothed mean of differences between consecutive transit times.
|
|
<BLOCKQUOTE><PRE><B>node2></B> iperf -s -u -i 1
|
|
------------------------------------------------------------
|
|
Server listening on UDP port 5001
|
|
Receiving 1470 byte datagrams
|
|
UDP buffer size: 60.0 KByte (default)
|
|
------------------------------------------------------------
|
|
[ 4] local <IP Addr node2> port 5001 connected with <IP Addr node1> port 9726
|
|
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
|
|
[ 4] 0.0- 1.0 sec 1.3 MBytes 10.0 Mbits/sec 0.209 ms 1/ 894 (0.11%)
|
|
[ 4] 1.0- 2.0 sec 1.3 MBytes 10.0 Mbits/sec 0.221 ms 0/ 892 (0%)
|
|
[ 4] 2.0- 3.0 sec 1.3 MBytes 10.0 Mbits/sec 0.277 ms 0/ 892 (0%)
|
|
[ 4] 3.0- 4.0 sec 1.3 MBytes 10.0 Mbits/sec 0.359 ms 0/ 893 (0%)
|
|
[ 4] 4.0- 5.0 sec 1.3 MBytes 10.0 Mbits/sec 0.251 ms 0/ 892 (0%)
|
|
[ 4] 5.0- 6.0 sec 1.3 MBytes 10.0 Mbits/sec 0.215 ms 0/ 892 (0%)
|
|
[ 4] 6.0- 7.0 sec 1.3 MBytes 10.0 Mbits/sec 0.325 ms 0/ 892 (0%)
|
|
[ 4] 7.0- 8.0 sec 1.3 MBytes 10.0 Mbits/sec 0.254 ms 0/ 892 (0%)
|
|
[ 4] 8.0- 9.0 sec 1.3 MBytes 10.0 Mbits/sec 0.282 ms 0/ 892 (0%)
|
|
[ 4] 0.0-10.0 sec 12.5 MBytes 10.0 Mbits/sec 0.243 ms 1/ 8922 (0.011%)
|
|
|
|
<B>node1></B> iperf -c node2 -u -b 10m
|
|
------------------------------------------------------------
|
|
Client connecting to node2, UDP port 5001
|
|
Sending 1470 byte datagrams
|
|
UDP buffer size: 60.0 KByte (default)
|
|
------------------------------------------------------------
|
|
[ 3] local <IP Addr node1> port 9726 connected with <IP Addr node2> port 5001
|
|
[ ID] Interval Transfer Bandwidth
|
|
[ 3] 0.0-10.0 sec 12.5 MBytes 10.0 Mbits/sec
|
|
[ 3] Sent 8922 datagrams</PRE></BLOCKQUOTE>Notice the higher jitter due to
|
|
datagram reassembly when using larger 32 KB datagrams, each split into 23
|
|
packets of 1500 bytes. The higher datagram loss seen here may be due to the
|
|
burstiness of the traffic, which is 23 back-to-back packets and then a long
|
|
pause, rather than evenly spaced individual packets.
|
|
<BLOCKQUOTE><PRE><B>node2></B> iperf -s -u -l 32k -w 128k -i 1
|
|
------------------------------------------------------------
|
|
Server listening on UDP port 5001
|
|
Receiving 32768 byte datagrams
|
|
UDP buffer size: 128 KByte
|
|
------------------------------------------------------------
|
|
[ 3] local <IP Addr node2> port 5001 connected with <IP Addr node1> port 11303
|
|
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
|
|
[ 3] 0.0- 1.0 sec 1.3 MBytes 10.0 Mbits/sec 0.430 ms 0/ 41 (0%)
|
|
[ 3] 1.0- 2.0 sec 1.1 MBytes 8.5 Mbits/sec 5.996 ms 6/ 40 (15%)
|
|
[ 3] 2.0- 3.0 sec 1.2 MBytes 9.7 Mbits/sec 0.796 ms 1/ 40 (2.5%)
|
|
[ 3] 3.0- 4.0 sec 1.2 MBytes 10.0 Mbits/sec 0.403 ms 0/ 40 (0%)
|
|
[ 3] 4.0- 5.0 sec 1.2 MBytes 10.0 Mbits/sec 0.448 ms 0/ 40 (0%)
|
|
[ 3] 5.0- 6.0 sec 1.2 MBytes 10.0 Mbits/sec 0.464 ms 0/ 40 (0%)
|
|
[ 3] 6.0- 7.0 sec 1.2 MBytes 10.0 Mbits/sec 0.442 ms 0/ 40 (0%)
|
|
[ 3] 7.0- 8.0 sec 1.2 MBytes 10.0 Mbits/sec 0.342 ms 0/ 40 (0%)
|
|
[ 3] 8.0- 9.0 sec 1.2 MBytes 10.0 Mbits/sec 0.431 ms 0/ 40 (0%)
|
|
[ 3] 9.0-10.0 sec 1.2 MBytes 10.0 Mbits/sec 0.407 ms 0/ 40 (0%)
|
|
[ 3] 0.0-10.0 sec 12.3 MBytes 9.8 Mbits/sec 0.407 ms 7/ 401 (1.7%)
|
|
|
|
<B>node1></B> iperf -c node2 -b 10m -l 32k -w 128k
|
|
------------------------------------------------------------
|
|
Client connecting to node2, UDP port 5001
|
|
Sending 32768 byte datagrams
|
|
UDP buffer size: 128 KByte
|
|
------------------------------------------------------------
|
|
[ 3] local <IP Addr node2> port 11303 connected with <IP Addr node1> port 5001
|
|
[ ID] Interval Transfer Bandwidth
|
|
[ 3] 0.0-10.0 sec 12.5 MBytes 10.0 Mbits/sec
|
|
[ 3] Sent 401 datagrams</PRE><PRE></PRE></BLOCKQUOTE>
|
|
<P><A name=multicast></A>
|
|
<B><FONT size=+1>Multicast</FONT></B>
|
|
<P>To test multicast, run several servers with the bind option (-B, --bind) set
|
|
to the multicast group address. Run the client, connecting to the multicast
|
|
group address and setting the TTL (-T, --ttl) as needed. Unlike normal TCP and
|
|
UDP tests, multicast servers may be started after the client. In that case,
|
|
datagrams sent before the server started show up as losses in the first periodic
|
|
report (61 datagrams on arno below).
|
|
<BLOCKQUOTE><PRE><B>node5></B> iperf -c 224.0.67.67 -u --ttl 5 -t 5
|
|
------------------------------------------------------------
|
|
Client connecting to 224.0.67.67, UDP port 5001
|
|
Sending 1470 byte datagrams
|
|
Setting multicast TTL to 5
|
|
UDP buffer size: 32.0 KByte (default)
|
|
------------------------------------------------------------
|
|
[ 3] local <IP Addr node5> port 1025 connected with 224.0.67.67 port 5001
|
|
[ ID] Interval Transfer Bandwidth
|
|
[ 3] 0.0- 5.0 sec 642 KBytes 1.0 Mbits/sec
|
|
[ 3] Sent 447 datagrams
|
|
|
|
<B>node5></B> iperf -s -u -B 224.0.67.67 -i 1
|
|
------------------------------------------------------------
|
|
Server listening on UDP port 5001
|
|
Binding to local address 224.0.67.67
|
|
Joining multicast group 224.0.67.67
|
|
Receiving 1470 byte datagrams
|
|
UDP buffer size: 32.0 KByte (default)
|
|
------------------------------------------------------------
|
|
[ 3] local 224.0.67.67 port 5001 connected with <IP Addr node5> port 1025
|
|
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
|
|
[ 3] 0.0- 1.0 sec 131 KBytes 1.0 Mbits/sec 0.007 ms 0/ 91 (0%)
|
|
[ 3] 1.0- 2.0 sec 128 KBytes 1.0 Mbits/sec 0.008 ms 0/ 89 (0%)
|
|
[ 3] 2.0- 3.0 sec 128 KBytes 1.0 Mbits/sec 0.010 ms 0/ 89 (0%)
|
|
[ 3] 3.0- 4.0 sec 128 KBytes 1.0 Mbits/sec 0.013 ms 0/ 89 (0%)
|
|
[ 3] 4.0- 5.0 sec 128 KBytes 1.0 Mbits/sec 0.008 ms 0/ 89 (0%)
|
|
[ 3] 0.0- 5.0 sec 642 KBytes 1.0 Mbits/sec 0.008 ms 0/ 447 (0%)
|
|
|
|
<B>node6></B> iperf -s -u -B 224.0.67.67 -i 1
|
|
------------------------------------------------------------
|
|
Server listening on UDP port 5001
|
|
Binding to local address 224.0.67.67
|
|
Joining multicast group 224.0.67.67
|
|
Receiving 1470 byte datagrams
|
|
UDP buffer size: 60.0 KByte (default)
|
|
------------------------------------------------------------
|
|
[ 3] local 224.0.67.67 port 5001 connected with <IP Addr node5> port 1025
|
|
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
|
|
[ 3] 0.0- 1.0 sec 129 KBytes 1.0 Mbits/sec 0.778 ms 61/ 151 (40%)
|
|
[ 3] 1.0- 2.0 sec 128 KBytes 1.0 Mbits/sec 0.236 ms 0/ 89 (0%)
|
|
[ 3] 2.0- 3.0 sec 128 KBytes 1.0 Mbits/sec 0.264 ms 0/ 89 (0%)
|
|
[ 3] 3.0- 4.0 sec 128 KBytes 1.0 Mbits/sec 0.248 ms 0/ 89 (0%)
|
|
[ 3] 0.0- 4.3 sec 554 KBytes 1.0 Mbits/sec 0.298 ms 61/ 447 (14%)</PRE><PRE><HR width="100%"></PRE></BLOCKQUOTE>
|
|
<P><A name=ipv6></A>
|
|
<DL>
|
|
<DT><B><FONT size=+2>IPv6 Mode</FONT></B>
|
|
<DD>Download the IPv6 version of this release.<BR>Get the IPv6 address of the node using the 'ifconfig' command.<BR>Use the <FONT color=#000099>-V</FONT> option to indicate that you are using an IPv6 address Please note that we need to explicitly bind the server address also.
|
|
<P>Server side:<BR><FONT color=#000099> $ iperf -s -V</FONT>
|
|
<P>Client side:<BR><FONT color=#000099>$ iperf -c <Server IPv6 Address> -V </FONT>
|
|
<P>Note: Iperf version 1.6.2 and eariler require a IPv6 address to be explicitly bound
|
|
with the <A HREF="#bind">-B</A> option for the server.</P></DD></DL>
|
|
<HR>
|
|
<P><A name=repmode></A>
|
|
<DL>
|
|
<DT><B><FONT size=+2>Using Representative Streams to measure
|
|
bandwidth</FONT></B>
|
|
<DD>Use the -F or -I option. If you want to test how your network performs
|
|
with compressed / uncompressed streams, just create representative streams and
|
|
use the -F option to test it. This is usually due to the link layer
|
|
compressing data.
|
|
<P>The -F option is for file input.<BR>The -I option is for input from stdin.
|
|
<P>E.g. <BR>Client: $ <FONT color=#000099> iperf -c <server address> -F <file-name><BR></FONT>
|
|
<BR>Client: $ <FONT color=#000099> iperf -c <server address> -I </FONT></P></DD></DL>
|
|
<P><A name=daemon></A>
|
|
<HR>
|
|
<DL>
|
|
<DT><B><FONT size=+2>Running the server as a daemon</FONT></B>
|
|
<DD>Use the -D command line option to run the server as a daemon. Redirect the
|
|
output to a file.<BR>E.g. <FONT color=#000099>iperf -s -D >
|
|
iperfLog</FONT>. <FONT color=#000000>This will have the Iperf Server running
|
|
as a daemon and the server messages will be logged in the file iperfLog.
|
|
</DD></DL>
|
|
<HR>
|
|
<P><A name=service></A>
|
|
<DL>
|
|
<DT><B><FONT size=+2>Using Iperf as a Service under Win32</FONT></B>
|
|
<DD>There are three options for Win32:
|
|
<P>
|
|
<DL>
|
|
<DT>-o outputfilename
|
|
<DD>output the messages into the specified file
|
|
<DT>-s -D
|
|
<DD>install Iperf as a service and run it
|
|
<DT>-s -R
|
|
<DD>uninstall the Iperf service </DD></DL>
|
|
<P>Examples:
|
|
<DL>
|
|
<DT><FONT color=#3366ff>iperf -s -D -o iperflog.txt</FONT>
|
|
<DD>will install the Iperf service and run it. Messages will be reported
|
|
into "%windir%\system32\iperflog.txt"
|
|
<P></P>
|
|
<DT><FONT color=#3366ff>iperf -s -R</FONT>
|
|
<DD>will uninstall the Iperf service if it is installed.
|
|
<P>Note: If you stop want to restart the Iperf service after having killed
|
|
it with the Microsoft Management Console or the Windows Task Manager, make
|
|
sure to use the proper OPTION in the service properties dialog.
|
|
</P></DD></DL></DD></DL>
|
|
<HR>
|
|
<!--<P><A name=multicast></A>
|
|
<DL>
|
|
<DT><B><FONT size=+2>Running the multicast server and client</FONT></B>
|
|
<DD>Use the -B option while starting the server to bind it to a multicast
|
|
address.<BR>E.g. :-<FONT color=#3366ff>iperf -s -u -B 224.0.55.55</FONT>.
|
|
|
|
<P>This will have the Iperf server listening for datagrams (-u) for the
|
|
address 224.0.55.55(-B 224.0.55.55).
|
|
<P>Now, start a client sending packets to this multicast address.
|
|
<P>E.g. : <FONT color=#3366ff>iperf -c 224.0.55.55 -u</FONT>.
|
|
This will have a UDP client (-u) sending to the multicast address
|
|
224.0.55.55(-c 224.0.55.55).
|
|
<P><FONT color=#000000>Start multiple clients or servers as explained above,
|
|
sending data to the same multicast server. (If you have multiple servers
|
|
listening on the multicast address, each of the servers will be getting the data)
|
|
</P></DD></DL>
|
|
<HR>-->
|
|
<!--<A name=adaptive></A>
|
|
<DL>
|
|
<DT><B><FONT size=+2>Adaptive window sizes</FONT></B>
|
|
<DD>Use the -W option on the client to run the client with the adaptive window
|
|
size. Ensure that the server window size is fairly big for this
|
|
option.<BR>E.g.. If the server TCP window size is 8KB, it does not help having
|
|
a client TCP window size of 256KB.<BR>256KB Server TCP Window Size should
|
|
suffice for most high bandwidth networks.
|
|
<P>Client changes the TCP window size using a binary exponential
|
|
algorithm. This means that you may notice that TCP window size suggested may
|
|
vary according to the traffic in the network, Iperf will suggest the best
|
|
window size for the current network scenario.
|
|
</DL>
|
|
<HR width="100%">
|
|
--><P><!-- ----- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- -->
|
|
<CENTER>
|
|
<P>Copyright 1999,2000,2001,2002,2003,2004 <BR>The Board of Trustees of the University of
|
|
Illinois <BR>All rights reserved <BR>See <A
|
|
href="ui_license.html">UI License</A> for
|
|
complete details.</CENTER>
|
|
</BODY>
|
|
</HTML>
|
|
|