| <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> |
| |
