nexmon – Blame information for rev 1
?pathlinks?
Rev | Author | Line No. | Line |
---|---|---|---|
1 | office | 1 | <HTML> |
2 | <HEAD> |
||
3 | <TITLE>Iperf version 2.0.0</TITLE> |
||
4 | <!-- $Id: index.html,v 1.1.1.1 2004/05/18 01:50:44 kgibbs Exp $ --> |
||
5 | </HEAD> |
||
6 | |||
7 | <BODY BGCOLOR="#FFFFFF" LINK="#006633" VLINK="#669900" ALINK="#669966"> |
||
8 | |||
9 | <CENTER> |
||
10 | <P><IMG SRC="dast.gif" |
||
11 | ALT="Distributed Applications Support Team"></P> |
||
12 | </CENTER> |
||
13 | |||
14 | <H1>Iperf version 2.0.0</H1> |
||
15 | |||
16 | <H3>May 2004</H3> |
||
17 | |||
18 | <HR><!-- ----- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- --> |
||
19 | |||
20 | <H3>NLANR applications support |
||
21 | <BR><A HREF="http://dast.nlanr.net/">http://dast.nlanr.net/</A> |
||
22 | <BR><A HREF="mailto:dast@nlanr.net"><dast@nlanr.net></A> |
||
23 | </H3> |
||
24 | <P><FONT face="arial,helvetica"> |
||
25 | <H1>Iperf User Docs</H1> |
||
26 | <H4>Mark Gates<br> |
||
27 | Ajay Tirumala<BR> |
||
28 | Jon Dugan<BR> |
||
29 | Kevin Gibbs<BR> </H4> |
||
30 | |||
31 | May 2004 |
||
32 | <P></CENTER> |
||
33 | [<a href="#compiling">Compiling</A> | |
||
34 | <A href="#features">Features</A> | |
||
35 | <A href="#tuningtcp">Tuning a TCP connection</A> | |
||
36 | <A href="#tuningudp">Tuning a UDP connection</A> | |
||
37 | <A href="#multicast">Running multicast servers and clients</A> | |
||
38 | <A href="#ipv6">IPv6 Mode</A> | |
||
39 | <A href="#repmode">Representative Streams</A> | |
||
40 | <A href="#daemon"> Running Iperf as a daemon</A> | |
||
41 | <!--<A href="#adaptive">Adaptive Window Sizes</A> | --> |
||
42 | <A href="#service">Running Iperf as a Windows Service</A> ] |
||
43 | <HR> |
||
44 | <!-- ----- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- --> |
||
45 | <H2><A name=compiling></A>Compiling</H2> |
||
46 | |||
47 | Once you have the distribution, on UNIX, |
||
48 | unpack it using gzip and tar. That will create a new directory |
||
49 | 'iperf-<version#>' with the source files and documentation. |
||
50 | <P> |
||
51 | |||
52 | Iperf compiles cleanly on many systems including Linux, SGI IRIX, HP-UX, |
||
53 | Solaris, AIX, and Cray UNICOS. Use '<TT>make</TT>' to configure for your OS and |
||
54 | compile the source code. |
||
55 | |||
56 | <BLOCKQUOTE><PRE> |
||
57 | |||
58 | gunzip -c iperf-<version>.tar.gz | tar -xvf - |
||
59 | cd iperf-<version> |
||
60 | ./configure |
||
61 | make |
||
62 | |||
63 | </PRE></BLOCKQUOTE> |
||
64 | |||
65 | To install iperf, use '<TT>make install</TT>', |
||
66 | which will ask you where to install it. To recompile, the easiest way is to |
||
67 | start over. Do '<TT>make distclean</TT>' then '<TT>./configure; make</TT>'. See the Makefile |
||
68 | for more options. |
||
69 | <P> |
||
70 | |||
71 | If you have problems, please report them to <A href="mailto:dast@nlanr.net">dast@nlanr.net</A> and |
||
72 | we will try to fix them quickly. <BR> |
||
73 | |||
74 | <HR> |
||
75 | <!-- ----- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- --> |
||
76 | |||
77 | <H2><A name=features></A>Features</H2> |
||
78 | <UL> |
||
79 | <LI>TCP |
||
80 | <UL> |
||
81 | <LI>Measure bandwidth |
||
82 | <LI>Report MSS/MTU size and observed read sizes. |
||
83 | <LI>Support for TCP window size via socket buffers. |
||
84 | <LI>Multi-threaded if pthreads or Win32 threads are available. Client and |
||
85 | server can have multiple simultaneous connections. |
||
86 | <!-- <LI>Suggest the optimal window size for a connection where the OS allows |
||
87 | setting window sizes in the granularity of bytes. </LI>--></UL> |
||
88 | <LI>UDP |
||
89 | <UL> |
||
90 | <LI>Client can create UDP streams of specified bandwidth. |
||
91 | <LI>Measure packet loss |
||
92 | <LI>Measure delay jitter |
||
93 | <LI>Multicast capable |
||
94 | <LI>Multi-threaded if pthreads are available. Client and server can have |
||
95 | multiple simultaneous connections. (This doesn't work in Windows.) </LI></UL> |
||
96 | <LI>Where appropriate, options can be specified with K (kilo-) and M (mega-) |
||
97 | suffices. So 128K instead of 131072 bytes. |
||
98 | <LI>Can run for specified time, rather than a set amount of data to transfer. |
||
99 | <LI>Picks the best units for the size of data being reported. |
||
100 | <LI>Server handles multiple connections, rather than quitting after a single |
||
101 | test. |
||
102 | <LI>Print periodic, intermediate bandwidth, jitter, and loss reports at |
||
103 | specified intervals. |
||
104 | <LI>Run the server as a daemon (Check out <A |
||
105 | href="http://www-itg.lbl.gov/nettest">Nettest</A> for running it as a secure |
||
106 | daemon). |
||
107 | <LI>Run the server as a Windows NT Service |
||
108 | <LI>Use representative streams to test out how link layer compression affects |
||
109 | your achievable bandwidth. |
||
110 | |||
111 | <!-- <LI>A library of <A |
||
112 | href="lib.html">useful functions and C++ |
||
113 | classes.</A> </LI> |
||
114 | --> |
||
115 | </UL> |
||
116 | <HR> |
||
117 | <!-- ----- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- --><BR> |
||
118 | |||
119 | <TABLE cellPadding=3 border=1> |
||
120 | <TBODY> |
||
121 | <TR vAlign=top> |
||
122 | <TH align=left>Command line option</TH> |
||
123 | <TH align=left>Environment variable option</TH> |
||
124 | <TH align=left>Description</TH></TR> |
||
125 | <TR> |
||
126 | <TH bgColor=#cccccc colSpan=3>Client and Server options</TH></TR> |
||
127 | <TR vAlign=top> |
||
128 | <TD><A name=format></A><TT>-f, --format <I>[bkmaBKMA]</I></TT></TD> |
||
129 | <TD><TT>$IPERF_FORMAT</TT></TD> |
||
130 | <TD>A letter specifying the format to print bandwidth numbers in. |
||
131 | Supported formats are |
||
132 | <PRE> |
||
133 | 'b' = bits/sec 'B' = Bytes/sec |
||
134 | 'k' = Kbits/sec 'K' = KBytes/sec |
||
135 | 'm' = Mbits/sec 'M' = MBytes/sec |
||
136 | 'g' = Gbits/sec 'G' = GBytes/sec |
||
137 | 'a' = adaptive bits/sec 'A' = adaptive Bytes/sec |
||
138 | </PRE> |
||
139 | The adaptive formats choose between kilo- and mega- as appropriate. Fields |
||
140 | other than bandwidth always print bytes, but otherwise follow the |
||
141 | requested format. Default is 'a'. <BR><I>NOTE:</I> here Kilo = 1024, |
||
142 | Mega = 1024^2 and Giga = 1024^3 when dealing with bytes. Commonly in networking, |
||
143 | Kilo = 1000, Mega = 1000^2, and Giga = 1000^3 so we use this when dealing with |
||
144 | bits. If this really bothers you, use -f b and do the math.</TD></TR> |
||
145 | <TR vAlign=top> |
||
146 | <TD><A name=interval></A><TT>-i, --interval <I>#</I></TT></TD> |
||
147 | <TD><TT>$IPERF_INTERVAL</TT></TD> |
||
148 | <TD>Sets the interval time in seconds between periodic bandwidth, jitter, |
||
149 | and loss reports. If non-zero, a report is made every <I>interval</I> |
||
150 | seconds of the bandwidth since the last report. If zero, no periodic |
||
151 | reports are printed. Default is zero.</TD></TR> |
||
152 | <TR vAlign=top> |
||
153 | <TD><A name=len></A><TT>-l, --len <I>#[KM]</I></TT></TD> |
||
154 | <TD><TT>$IPERF_LEN</TT></TD> |
||
155 | <TD>The length of buffers to read or write. Iperf works by writing an |
||
156 | array of <I>len</I> bytes a number of times. Default is 8 KB for TCP, 1470 |
||
157 | bytes for UDP. Note for UDP, this is the datagram size and needs to be lowered when using |
||
158 | IPv6 addressing to 1450 or less to avoid fragmentation. See also the <A |
||
159 | href="#num">-n</A> |
||
160 | and <A |
||
161 | href="#time">-t</A> |
||
162 | options.</TD></TR> |
||
163 | <TR vAlign=top> |
||
164 | <TD><A name=print_mss></A><TT>-m, --print_mss</TT></TD> |
||
165 | <TD><TT>$IPERF_PRINT_MSS</TT></TD> |
||
166 | <TD>Print the reported TCP MSS size (via the TCP_MAXSEG option) and the |
||
167 | observed read sizes which often correlate with the MSS. The MSS is usually |
||
168 | the MTU - 40 bytes for the TCP/IP header. Often a slightly smaller MSS is |
||
169 | reported because of extra header space from IP options. The interface type |
||
170 | corresponding to the MTU is also printed (ethernet, FDDI, etc.). This |
||
171 | option is not implemented on many OSes, but the read sizes may still |
||
172 | indicate the MSS.</TD></TR> |
||
173 | <TR vAlign=top> |
||
174 | <TD><A name=port></A><TT>-p, --port <I>#</I></TT></TD> |
||
175 | <TD><TT>$IPERF_PORT</TT></TD> |
||
176 | <TD>The server port for the server to listen on and the client to connect |
||
177 | to. This should be the same in both client and server. Default is 5001, |
||
178 | the same as ttcp.</TD></TR> |
||
179 | <TR vAlign=top> |
||
180 | <TD><A name=udp></A><TT>-u, --udp</TT></TD> |
||
181 | <TD><TT>$IPERF_UDP</TT></TD> |
||
182 | <TD>Use UDP rather than TCP. See also the <A |
||
183 | href="#bandwidth">-b</A> |
||
184 | option.</TD></TR> |
||
185 | <TR vAlign=top> |
||
186 | <TD><A name=window></A><TT>-w, --window <I>#[KM]</I></TT></TD> |
||
187 | <TD><TT>$TCP_WINDOW_SIZE</TT></TD> |
||
188 | <TD>Sets the socket buffer sizes to the specified value. For TCP, this |
||
189 | sets the TCP window size. For UDP it is just the buffer which datagrams |
||
190 | are received in, and so limits the largest receivable datagram size.</TD></TR> |
||
191 | <TR vAlign=top> |
||
192 | <TD><A name=bind></A><TT>-B, --bind <I>host</I></TT></TD> |
||
193 | <TD><TT>$IPERF_BIND</TT></TD> |
||
194 | <TD>Bind to <I>host</I>, one of this machine's addresses. For the client |
||
195 | this sets the outbound interface. For a server this sets the incoming |
||
196 | interface. This is only useful on multihomed hosts, which have multiple |
||
197 | network interfaces. |
||
198 | <P>For Iperf in UDP server mode, this is also used to bind and join to a |
||
199 | multicast group. Use addresses in the range 224.0.0.0 to 239.255.255.255 |
||
200 | for multicast. See also the <A |
||
201 | href="#ttl">-T</A> |
||
202 | option.</P></TD></TR> |
||
203 | <TR vAlign=top> |
||
204 | <TD><A name=compatibility></A><TT>-C, --compatibility </TT></TD> |
||
205 | <TD><TT>$IPERF_COMPAT</TT></TD> |
||
206 | <TD>Compatibility mode allows for use with older version of iperf. This mode |
||
207 | is not required for interoperability but it is highly recommended. In |
||
208 | some cases when using representative streaming you could cause a 1.7 server |
||
209 | to crash or cause undesired connection attempts.</P></TD></TR> |
||
210 | <TR vAlign=top> |
||
211 | <TD><A name=mss></A><TT>-M, --mss <I>#[KM}</I></TT></TD> |
||
212 | <TD><TT>$IPERF_MSS</TT></TD> |
||
213 | <TD>Attempt to set the TCP maximum segment size (MSS) via the TCP_MAXSEG |
||
214 | option. The MSS is usually the MTU - 40 bytes for the TCP/IP header. For |
||
215 | ethernet, the MSS is 1460 bytes (1500 byte MTU). This option is not |
||
216 | implemented on many OSes.</TD></TR> |
||
217 | <TR vAlign=top> |
||
218 | <TD><A name=nodelay></A><TT>-N, --nodelay</TT></TD> |
||
219 | <TD><TT>$IPERF_NODELAY</TT></TD> |
||
220 | <TD>Set the TCP no delay option, disabling Nagle's algorithm. Normally |
||
221 | this is only disabled for interactive applications like telnet.</TD></TR> |
||
222 | <TR> |
||
223 | <TD><TT>-V </TT>(from v1.6 or higher)</TD> |
||
224 | <TD>.</TD> |
||
225 | <TD>Bind to an IPv6 address <BR>Server side: <BR>$ iperf -s -V |
||
226 | <P>Client side: <BR>$ iperf -c <Server IPv6 Address> -V |
||
227 | <BR> </P>Note: On version 1.6.3 and later a specific IPv6 Address does |
||
228 | not need to be bound with the <A href="#bind">-B</A> option, previous 1.6 |
||
229 | versions do. Also on most OSes using this option will also respond to IPv4 |
||
230 | clients using IPv4 mapped addresses.</TD></TR> |
||
231 | <TR> |
||
232 | <TH bgColor=#cccccc colSpan=3>Server specific options</TH></TR> |
||
233 | <TR vAlign=top> |
||
234 | <TD><A name=server></A><TT>-s, --server</TT></TD> |
||
235 | <TD><TT>$IPERF_SERVER</TT></TD> |
||
236 | <TD>Run Iperf in server mode.</TD></TR> |
||
237 | <TR> |
||
238 | <TD><TT>-D </TT> (from v1.2 or higher)</TD> |
||
239 | <TD>.</TD> |
||
240 | <TD>Run the server as a daemon (Unix platforms) <BR>On Win32 platforms |
||
241 | where services are available, Iperf will start running as a service.</TD></TR> |
||
242 | <TR> |
||
243 | <TD><TT>-R </TT>(only for Windows, from v1.2 or higher)</TD> |
||
244 | <TD>.</TD> |
||
245 | <TD>Remove the Iperf service (if it's running). </TD></TR><TR> |
||
246 | <TD><TT>-o </TT>(only for Windows, from v1.2 or higher)</TD> |
||
247 | <TD>.</TD> |
||
248 | <TD>Redirect output to given file. </TD></TR> |
||
249 | <TR vAlign=top> |
||
250 | <TD><A name=sclient></A><TT>-c, --client <I>host</I></TT></TD> |
||
251 | <TD><TT>$IPERF_CLIENT</TT></TD> |
||
252 | <TD> If Iperf is in server mode, then specifying a host with -c |
||
253 | will limit the connections that Iperf will accept to the |
||
254 | <I>host</I> specified. Does not work well for UDP.</TD></TR> |
||
255 | <TR vAlign=top> |
||
256 | <TD><A name=sparallel></A><TT>-P, --parallel <I>#</I></TT></TD> |
||
257 | <TD><TT>$IPERF_PARALLEL</TT></TD> |
||
258 | <TD>The number of connections to handle by the server before |
||
259 | closing. Default is 0 (which means to accept connections forever).</TD></TR> |
||
260 | <TR> |
||
261 | <TH bgColor=#cccccc colSpan=3>Client specific options</TH></TR> |
||
262 | <TR vAlign=top> |
||
263 | <TD><A name=bandwidth></A><TT>-b, --bandwidth <I>#[KM]</I></TT></TD> |
||
264 | <TD><TT>$IPERF_BANDWIDTH</TT></TD> |
||
265 | <TD>The UDP bandwidth to send at, in bits/sec. This implies the -u option. |
||
266 | Default is 1 Mbit/sec.</TD></TR> |
||
267 | <TR vAlign=top> |
||
268 | <TD><A name=client></A><TT>-c, --client <I>host</I></TT></TD> |
||
269 | <TD><TT>$IPERF_CLIENT</TT></TD> |
||
270 | <TD>Run Iperf in client mode, connecting to an Iperf server running on |
||
271 | <I>host</I>.</TD></TR> |
||
272 | <TR vAlign=top> |
||
273 | <TD><A name=dualtest></A><TT>-d, --dualtest </TT></TD> |
||
274 | <TD><TT>$IPERF_DUALTEST</TT></TD> |
||
275 | <TD>Run Iperf in dual testing mode. This will cause the server to connect |
||
276 | back to the client on the port specified in the |
||
277 | <A href="#listenport">-L</A> option (or defaults |
||
278 | to the port the client connected to the server on). This is done immediately |
||
279 | therefore running the tests simultaneously. If you want an alternating |
||
280 | test try <A href="#tradeoff">-r.</A></TD></TR> |
||
281 | <TR vAlign=top> |
||
282 | <TD><A name=num></A><TT>-n, --num <I>#[KM]</I></TT></TD> |
||
283 | <TD><TT>$IPERF_NUM</TT></TD> |
||
284 | <TD>The number of buffers to transmit. Normally, Iperf sends for 10 |
||
285 | seconds. The -n option overrides this and sends an array of <I>len</I> |
||
286 | bytes <I>num</I> times, no matter how long that takes. See also the <A |
||
287 | href="#len">-l</A> |
||
288 | and <A |
||
289 | href="#time">-t</A> |
||
290 | options.</TD></TR> |
||
291 | <TR vAlign=top> |
||
292 | <TD><A name=tradeoff></A><TT>-r, --tradeoff </TT></TD> |
||
293 | <TD><TT>$IPERF_TRADEOFF</TT></TD> |
||
294 | <TD>Run Iperf in tradeoff testing mode. This will cause the server to connect |
||
295 | back to the client on the port specified in the |
||
296 | <A href="#listenport">-L</A> option (or defaults |
||
297 | to the port the client connected to the server on). This is done following |
||
298 | the client connection termination, therefore running the tests |
||
299 | alternating. If you want an simultaneous test try |
||
300 | <A href="#dualtest">-d.</A></TD></TR> |
||
301 | <TR vAlign=top> |
||
302 | <TD><A name=time></A><TT>-t, --time <I>#</I></TT></TD> |
||
303 | <TD><TT>$IPERF_TIME</TT></TD> |
||
304 | <TD>The time in seconds to transmit for. Iperf normally works by |
||
305 | repeatedly sending an array of <I>len</I> bytes for <I>time</I> seconds. |
||
306 | Default is 10 seconds. See also the <A |
||
307 | href="#len">-l</A> |
||
308 | and <A |
||
309 | href="#num">-n</A> |
||
310 | options.</TD></TR> |
||
311 | <TR vAlign=top> |
||
312 | <TD><A name=listenport></A><TT>-L, --listenport <I>#</I></TT></TD> |
||
313 | <TD><TT>$IPERF_LISTENPORT</TT></TD> |
||
314 | <TD>This specifies the port that the server will connect back to the |
||
315 | client on. It defaults to the port used to connect to the server |
||
316 | from the client.</TD></TR> |
||
317 | <TR vAlign=top> |
||
318 | <TD><A name=parallel></A><TT>-P, --parallel <I>#</I></TT></TD> |
||
319 | <TD><TT>$IPERF_PARALLEL</TT></TD> |
||
320 | <TD>The number of simultaneous connections to make to the server. Default |
||
321 | is 1. Requires thread support on both the client and server.</TD></TR> |
||
322 | <TR vAlign=top> |
||
323 | <TD><A name=tos></A><TT>-S, --tos <I>#</I></TT></TD> |
||
324 | <TD><TT>$IPERF_TOS</TT></TD> |
||
325 | <TD>The type-of-service for outgoing packets. (Many routers ignore the TOS |
||
326 | field.) You may specify the value in hex with a '0x' prefix, in octal with |
||
327 | a '0' prefix, or in decimal. For example, '0x10' hex = '020' octal = '16' |
||
328 | decimal. The TOS numbers specified in RFC 1349 are: |
||
329 | <PRE> |
||
330 | IPTOS_LOWDELAY minimize delay 0x10 |
||
331 | IPTOS_THROUGHPUT maximize throughput 0x08 |
||
332 | IPTOS_RELIABILITY maximize reliability 0x04 |
||
333 | IPTOS_LOWCOST minimize cost 0x02 |
||
334 | |
||
335 | </PRE> |
||
336 | </TD></TR> |
||
337 | <TR vAlign=top> |
||
338 | <TD><A name=ttl></A><TT>-T, --ttl <I>#</I></TT></TD> |
||
339 | <TD><TT>$IPERF_TTL</TT></TD> |
||
340 | <TD>The time-to-live for outgoing multicast packets. This is essentially |
||
341 | the number of router hops to go through, and is also used for scoping. |
||
342 | Default is 1, link-local.</TD></TR> |
||
343 | <TR> |
||
344 | <TD><TT>-F</TT> (from v1.2 or higher)</TD> |
||
345 | <TD>.</TD> |
||
346 | <TD>Use a representative stream to measure bandwidth, e.g. :- <BR>$ |
||
347 | iperf -c <server address> -F <file-name></TD></TR> |
||
348 | <TR> |
||
349 | <TD><TT>-I </TT>(from v1.2 or higher)</TD> |
||
350 | <TD>.</TD> |
||
351 | <TD>Same as -F, input from stdin.</TD></TR> |
||
352 | <!-- <TR> |
||
353 | <TD><TT>-W </TT>(from v1.2 or higher)</TD> |
||
354 | <TD>.</TD> |
||
355 | <TD>Adaptive Window Sizes. |
||
356 | <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> |
||
357 | --> <TR> |
||
358 | <TH bgColor=#cccccc colSpan=3>Miscellaneous options</TH></TR> |
||
359 | <TR vAlign=top> |
||
360 | <TD><A name=help></A><TT>-h, --help</TT></TD> |
||
361 | <TD> </TD> |
||
362 | <TD>Print out a summary of commands and quit.</TD></TR> |
||
363 | <TR vAlign=top> |
||
364 | <TD><A name=version></A><TT>-v, --version</TT></TD> |
||
365 | <TD> </TD> |
||
366 | <TD>Print version information and quit. Prints 'pthreads' if compiled with |
||
367 | POSIX threads, 'win32 threads' if compiled with Microsoft Win32 threads, |
||
368 | or 'single threaded' if compiled without threads.</TD></TR></TBODY></TABLE> |
||
369 | <P> |
||
370 | <HR> |
||
371 | <!-- ----- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- --> |
||
372 | <H2><A name=tuningtcp></A>Tuning a TCP connection</H2> |
||
373 | |||
374 | The primary goal of Iperf |
||
375 | is to help in tuning TCP connections over a particular path. The most |
||
376 | fundamental tuning issue for TCP is the TCP window size, which controls how much |
||
377 | data can be in the network at any one point. If it is too small, the sender will |
||
378 | be idle at times and get poor performance. The theoretical value to use for the |
||
379 | TCP window size is the <I>bandwidth delay product</I>, |
||
380 | <BLOCKQUOTE>bottleneck bandwidth * round trip time</BLOCKQUOTE>In the below |
||
381 | modi4/cyclops example, the bottleneck link is a 45 Mbit/sec DS3 link and the |
||
382 | round trip time measured with ping is 42 ms. The bandwidth delay product is |
||
383 | <BLOCKQUOTE>45 Mbit/sec * 42 ms <BR>= (45e6) * (42e-3) <BR>= 1890000 bits |
||
384 | <BR>= 230 KByte</BLOCKQUOTE>That is a starting point for figuring the best |
||
385 | window size; setting it higher or lower may produce better results. In our |
||
386 | example, buffer sizes over 130K did not improve the performance, despite the |
||
387 | bandwidth delay product of 230K. |
||
388 | <P>Note that many OSes and hosts have upper limits on the TCP window size. These |
||
389 | may be as low as 64 KB, or as high as several MB. Iperf tries to detect when |
||
390 | these occur and give a warning that the actual and requested window sizes are |
||
391 | not equal (as below, though that is due to rounding in IRIX). PSC has a <A |
||
392 | href="http://www.psc.edu/networking/perf_tune.html">list detailing</A> how to |
||
393 | change the default and maximum window sizes for various OSes. For more |
||
394 | information on TCP window sizes, see the <A |
||
395 | href="http://dast.nlanr.net/Guides/GettingStarted/TCP_window_size.html">User's |
||
396 | Guide to TCP Windows.</A> |
||
397 | <P>Here is an example session, between node1 in Illinois and node2 in North |
||
398 | Carolina. These are connected via the vBNS backbone and a 45 Mbit/sec DS3 link. |
||
399 | Notice we improve bandwidth performance by a factor of 3 using proper TCP window |
||
400 | sizes. Use the adaptive window sizes feature on platforms which allow setting |
||
401 | window sizes in the granularity of bytes. |
||
402 | <BLOCKQUOTE> |
||
403 | <PRE> |
||
404 | <B>node2></B> iperf -s |
||
405 | ------------------------------------------------------------ |
||
406 | Server listening on TCP port 5001 |
||
407 | TCP window size: 60.0 KByte (default) |
||
408 | ------------------------------------------------------------ |
||
409 | [ 4] local <IP Addr node2> port 5001 connected with <IP Addr node1> port 2357 |
||
410 | [ ID] Interval Transfer Bandwidth |
||
411 | [ 4] 0.0-10.1 sec 6.5 MBytes <B><FONT color=#ff0000>5.2 Mbits/sec |
||
412 | |||
413 | </FONT>node1></B> iperf -c node2 |
||
414 | ------------------------------------------------------------ |
||
415 | Client connecting to node1, TCP port 5001 |
||
416 | TCP window size: 59.9 KByte (default) |
||
417 | ------------------------------------------------------------ |
||
418 | [ 3] local <IP Addr node1> port 2357 connected with <IP Addr node2> port 5001 |
||
419 | [ ID] Interval Transfer Bandwidth |
||
420 | [ 3] 0.0-10.0 sec 6.5 MBytes 5.2 Mbits/sec</PRE> |
||
421 | <HR> |
||
422 | <PRE><B>node2></B> iperf -s -w 130k |
||
423 | ------------------------------------------------------------ |
||
424 | Server listening on TCP port 5001 |
||
425 | TCP window size: 130 KByte |
||
426 | ------------------------------------------------------------ |
||
427 | [ 4] local <IP Addr node 2> port 5001 connected with <IP Addr node 1> port 2530 |
||
428 | [ ID] Interval Transfer Bandwidth |
||
429 | [ 4] 0.0-10.1 sec 19.7 MBytes <B><FONT color=#ff0000>15.7 Mbits/sec |
||
430 | |||
431 | </FONT>node1></B> iperf -c node2 -w 130k |
||
432 | ------------------------------------------------------------ |
||
433 | Client connecting to node2, TCP port 5001 |
||
434 | TCP window size: 129 KByte (WARNING: requested 130 KByte) |
||
435 | ------------------------------------------------------------ |
||
436 | [ 3] local <IP Addr node1> port 2530 connected with <IP Addr node2> port 5001 |
||
437 | [ ID] Interval Transfer Bandwidth |
||
438 | [ 3] 0.0-10.0 sec 19.7 MBytes 15.8 Mbits/sec</PRE></BLOCKQUOTE>Another |
||
439 | test to do is run parallel TCP streams. If the total aggregate bandwidth is more |
||
440 | than what an individual stream gets, something is wrong. Either the TCP window |
||
441 | size is too small, or the OS's TCP implementation has bugs, or the network |
||
442 | itself has deficiencies. See above for TCP window sizes; otherwise diagnosing |
||
443 | which is somewhat difficult. If Iperf is compiled with pthreads, a single client |
||
444 | and server can test this, otherwise setup multiple clients and servers on |
||
445 | different ports. Here's an example where a single stream gets 16.5 Mbit/sec, but |
||
446 | two parallel streams together get 16.7 + 9.4 = 26.1 Mbit/sec, even when using |
||
447 | large TCP window sizes: |
||
448 | <BLOCKQUOTE><PRE><B>node2></B> iperf -s -w 300k |
||
449 | ------------------------------------------------------------ |
||
450 | Server listening on TCP port 5001 |
||
451 | TCP window size: 300 KByte |
||
452 | ------------------------------------------------------------ |
||
453 | [ 4] local <IP Addr node2> port 5001 connected with <IP Addr node1> port 6902 |
||
454 | [ ID] Interval Transfer Bandwidth |
||
455 | [ 4] 0.0-10.2 sec 20.9 MBytes <B><FONT color=#ff0000>16.5 Mbits/sec |
||
456 | |||
457 | </FONT></B>[ 4] local <IP Addr node2> port 5001 connected with <IP Addr node1> port 6911 |
||
458 | [ 5] local <IP Addr node2> port 5001 connected with <IP Addr node2> port 6912 |
||
459 | [ ID] Interval Transfer Bandwidth |
||
460 | [ 5] 0.0-10.1 sec 21.0 MBytes <B><FONT color=#ff0000>16.7 Mbits/sec |
||
461 | </FONT></B>[ 4] 0.0-10.3 sec 12.0 MBytes <B><FONT color=#ff0000> 9.4 Mbits/sec |
||
462 | |||
463 | </FONT>node1></B> ./iperf -c node2 -w 300k |
||
464 | ------------------------------------------------------------ |
||
465 | Client connecting to node2, TCP port 5001 |
||
466 | TCP window size: 299 KByte (WARNING: requested 300 KByte) |
||
467 | ------------------------------------------------------------ |
||
468 | [ 3] local <IP Addr node2> port 6902 connected with <IP Addr node1> port 5001 |
||
469 | [ ID] Interval Transfer Bandwidth |
||
470 | [ 3] 0.0-10.2 sec 20.9 MBytes 16.4 Mbits/sec |
||
471 | |||
472 | <B>node1></B> iperf -c node2 -w 300k -P 2 |
||
473 | ------------------------------------------------------------ |
||
474 | Client connecting to node2, TCP port 5001 |
||
475 | TCP window size: 299 KByte (WARNING: requested 300 KByte) |
||
476 | ------------------------------------------------------------ |
||
477 | [ 4] local <IP Addr node2> port 6912 connected with <IP Addr node1> port 5001 |
||
478 | [ 3] local <IP Addr node2> port 6911 connected with <IP Addr node1> port 5001 |
||
479 | [ ID] Interval Transfer Bandwidth |
||
480 | [ 4] 0.0-10.1 sec 21.0 MBytes 16.6 Mbits/sec |
||
481 | [ 3] 0.0-10.2 sec 12.0 MBytes 9.4 Mbits/sec</PRE></BLOCKQUOTE>A |
||
482 | secondary tuning issue for TCP is the maximum transmission unit (MTU). To be |
||
483 | most effective, both hosts should support Path MTU Discovery. PSC has a <A |
||
484 | href="http://www.psc.edu/networking/perf_tune.html">list detailing</A> what OSes |
||
485 | support Path MTU Discovery. Hosts without Path MTU Discovery often use 536 as |
||
486 | the MSS, which wastes bandwidth and processing time. Use the -m option to |
||
487 | display what MSS is being used, and see if this matches what you expect. Often |
||
488 | it is around 1460 bytes for ethernet. |
||
489 | <BLOCKQUOTE><PRE><B>node3></B> iperf -s -m |
||
490 | ------------------------------------------------------------ |
||
491 | Server listening on TCP port 5001 |
||
492 | TCP window size: 60.0 KByte (default) |
||
493 | ------------------------------------------------------------ |
||
494 | [ 4] local <IP Addr node3> port 5001 connected with <IP Addr node4> port 1096 |
||
495 | [ ID] Interval Transfer Bandwidth |
||
496 | [ 4] 0.0- 2.0 sec 1.8 MBytes 6.9 Mbits/sec |
||
497 | [ 4] <B><FONT color=#ff0000>MSS size 1448 bytes (MTU 1500 bytes, ethernet) |
||
498 | </FONT></B>[ 4] Read lengths occurring in more than 5% of reads: |
||
499 | [ 4] 952 bytes read 219 times (16.2%) |
||
500 | [ 4] 1448 bytes read 1128 times (83.6%)</PRE></BLOCKQUOTE>Here |
||
501 | is a host that doesn't support Path MTU Discovery. It will only send and receive |
||
502 | small 576 byte packets. |
||
503 | <BLOCKQUOTE><PRE><B>node4></B> iperf -s -m |
||
504 | ------------------------------------------------------------ |
||
505 | Server listening on TCP port 5001 |
||
506 | TCP window size: 32.0 KByte (default) |
||
507 | ------------------------------------------------------------ |
||
508 | [ 4] local <IP Addr node4> port 5001 connected with <IP Addr node3> port 13914 |
||
509 | [ ID] Interval Transfer Bandwidth |
||
510 | [ 4] 0.0- 2.3 sec 632 KBytes 2.1 Mbits/sec |
||
511 | <B><FONT color=#ff0000>WARNING: Path MTU Discovery may not be enabled. |
||
512 | </FONT></B>[ 4] <B><FONT color=#ff0000>MSS size 536 bytes (MTU 576 bytes, minimum) |
||
513 | </FONT></B>[ 4] Read lengths occurring in more than 5% of reads: |
||
514 | [ 4] 536 bytes read 308 times (58.4%) |
||
515 | [ 4] 1072 bytes read 91 times (17.3%) |
||
516 | [ 4] 1608 bytes read 29 times (5.5%)</PRE></BLOCKQUOTE>Iperf |
||
517 | supports other tuning options, which were added for exceptional network |
||
518 | situations like HIPPI-to-HIPPI over ATM. <BR> |
||
519 | <HR> |
||
520 | <!-- ----- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- --> |
||
521 | |||
522 | <H2><A name=tuningudp></A>Tuning a UDP connection</H2> |
||
523 | |||
524 | Iperf creates a constant bit rate UDP stream. This is a very artificial |
||
525 | stream, similar to voice communication but not much else. |
||
526 | <P> |
||
527 | |||
528 | You will want to adjust the datagram size (-l) to the size your application |
||
529 | uses. |
||
530 | <P> |
||
531 | |||
532 | The server detects UDP datagram loss by ID numbers in the datagrams. Usually |
||
533 | a UDP datagram becomes several IP packets. Losing a single IP packet will lose |
||
534 | the entire datagram. To measure packet loss instead of datagram loss, make the |
||
535 | datagrams small enough to fit into a single packet, using the -l option. The |
||
536 | default size of 1470 bytes works for ethernet. Out-of-order packets are also |
||
537 | detected. (Out-of-order packets cause some ambiguity in the lost packet count; |
||
538 | Iperf assumes they are not duplicate packets, so they are excluded from the lost |
||
539 | packet count.) Since TCP does not report loss to the user, I find UDP tests |
||
540 | helpful to see packet loss along a path. |
||
541 | <P> |
||
542 | |||
543 | Jitter calculations are continuously computed by the server, as specified by |
||
544 | RTP in RFC 1889. The client records a 64 bit second/microsecond timestamp in the |
||
545 | packet. The server computes the relative transit time as (server's receive time |
||
546 | - client's send time). The client's and server's clocks do not need to be |
||
547 | synchronized; any difference is subtracted out in the jitter calculation. Jitter |
||
548 | is the smoothed mean of differences between consecutive transit times. |
||
549 | <BLOCKQUOTE><PRE><B>node2></B> iperf -s -u -i 1 |
||
550 | ------------------------------------------------------------ |
||
551 | Server listening on UDP port 5001 |
||
552 | Receiving 1470 byte datagrams |
||
553 | UDP buffer size: 60.0 KByte (default) |
||
554 | ------------------------------------------------------------ |
||
555 | [ 4] local <IP Addr node2> port 5001 connected with <IP Addr node1> port 9726 |
||
556 | [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams |
||
557 | [ 4] 0.0- 1.0 sec 1.3 MBytes 10.0 Mbits/sec 0.209 ms 1/ 894 (0.11%) |
||
558 | [ 4] 1.0- 2.0 sec 1.3 MBytes 10.0 Mbits/sec 0.221 ms 0/ 892 (0%) |
||
559 | [ 4] 2.0- 3.0 sec 1.3 MBytes 10.0 Mbits/sec 0.277 ms 0/ 892 (0%) |
||
560 | [ 4] 3.0- 4.0 sec 1.3 MBytes 10.0 Mbits/sec 0.359 ms 0/ 893 (0%) |
||
561 | [ 4] 4.0- 5.0 sec 1.3 MBytes 10.0 Mbits/sec 0.251 ms 0/ 892 (0%) |
||
562 | [ 4] 5.0- 6.0 sec 1.3 MBytes 10.0 Mbits/sec 0.215 ms 0/ 892 (0%) |
||
563 | [ 4] 6.0- 7.0 sec 1.3 MBytes 10.0 Mbits/sec 0.325 ms 0/ 892 (0%) |
||
564 | [ 4] 7.0- 8.0 sec 1.3 MBytes 10.0 Mbits/sec 0.254 ms 0/ 892 (0%) |
||
565 | [ 4] 8.0- 9.0 sec 1.3 MBytes 10.0 Mbits/sec 0.282 ms 0/ 892 (0%) |
||
566 | [ 4] 0.0-10.0 sec 12.5 MBytes 10.0 Mbits/sec 0.243 ms 1/ 8922 (0.011%) |
||
567 | |||
568 | <B>node1></B> iperf -c node2 -u -b 10m |
||
569 | ------------------------------------------------------------ |
||
570 | Client connecting to node2, UDP port 5001 |
||
571 | Sending 1470 byte datagrams |
||
572 | UDP buffer size: 60.0 KByte (default) |
||
573 | ------------------------------------------------------------ |
||
574 | [ 3] local <IP Addr node1> port 9726 connected with <IP Addr node2> port 5001 |
||
575 | [ ID] Interval Transfer Bandwidth |
||
576 | [ 3] 0.0-10.0 sec 12.5 MBytes 10.0 Mbits/sec |
||
577 | [ 3] Sent 8922 datagrams</PRE></BLOCKQUOTE>Notice the higher jitter due to |
||
578 | datagram reassembly when using larger 32 KB datagrams, each split into 23 |
||
579 | packets of 1500 bytes. The higher datagram loss seen here may be due to the |
||
580 | burstiness of the traffic, which is 23 back-to-back packets and then a long |
||
581 | pause, rather than evenly spaced individual packets. |
||
582 | <BLOCKQUOTE><PRE><B>node2></B> iperf -s -u -l 32k -w 128k -i 1 |
||
583 | ------------------------------------------------------------ |
||
584 | Server listening on UDP port 5001 |
||
585 | Receiving 32768 byte datagrams |
||
586 | UDP buffer size: 128 KByte |
||
587 | ------------------------------------------------------------ |
||
588 | [ 3] local <IP Addr node2> port 5001 connected with <IP Addr node1> port 11303 |
||
589 | [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams |
||
590 | [ 3] 0.0- 1.0 sec 1.3 MBytes 10.0 Mbits/sec 0.430 ms 0/ 41 (0%) |
||
591 | [ 3] 1.0- 2.0 sec 1.1 MBytes 8.5 Mbits/sec 5.996 ms 6/ 40 (15%) |
||
592 | [ 3] 2.0- 3.0 sec 1.2 MBytes 9.7 Mbits/sec 0.796 ms 1/ 40 (2.5%) |
||
593 | [ 3] 3.0- 4.0 sec 1.2 MBytes 10.0 Mbits/sec 0.403 ms 0/ 40 (0%) |
||
594 | [ 3] 4.0- 5.0 sec 1.2 MBytes 10.0 Mbits/sec 0.448 ms 0/ 40 (0%) |
||
595 | [ 3] 5.0- 6.0 sec 1.2 MBytes 10.0 Mbits/sec 0.464 ms 0/ 40 (0%) |
||
596 | [ 3] 6.0- 7.0 sec 1.2 MBytes 10.0 Mbits/sec 0.442 ms 0/ 40 (0%) |
||
597 | [ 3] 7.0- 8.0 sec 1.2 MBytes 10.0 Mbits/sec 0.342 ms 0/ 40 (0%) |
||
598 | [ 3] 8.0- 9.0 sec 1.2 MBytes 10.0 Mbits/sec 0.431 ms 0/ 40 (0%) |
||
599 | [ 3] 9.0-10.0 sec 1.2 MBytes 10.0 Mbits/sec 0.407 ms 0/ 40 (0%) |
||
600 | [ 3] 0.0-10.0 sec 12.3 MBytes 9.8 Mbits/sec 0.407 ms 7/ 401 (1.7%) |
||
601 | |||
602 | <B>node1></B> iperf -c node2 -b 10m -l 32k -w 128k |
||
603 | ------------------------------------------------------------ |
||
604 | Client connecting to node2, UDP port 5001 |
||
605 | Sending 32768 byte datagrams |
||
606 | UDP buffer size: 128 KByte |
||
607 | ------------------------------------------------------------ |
||
608 | [ 3] local <IP Addr node2> port 11303 connected with <IP Addr node1> port 5001 |
||
609 | [ ID] Interval Transfer Bandwidth |
||
610 | [ 3] 0.0-10.0 sec 12.5 MBytes 10.0 Mbits/sec |
||
611 | [ 3] Sent 401 datagrams</PRE><PRE></PRE></BLOCKQUOTE> |
||
612 | <P><A name=multicast></A> |
||
613 | <B><FONT size=+1>Multicast</FONT></B> |
||
614 | <P>To test multicast, run several servers with the bind option (-B, --bind) set |
||
615 | to the multicast group address. Run the client, connecting to the multicast |
||
616 | group address and setting the TTL (-T, --ttl) as needed. Unlike normal TCP and |
||
617 | UDP tests, multicast servers may be started after the client. In that case, |
||
618 | datagrams sent before the server started show up as losses in the first periodic |
||
619 | report (61 datagrams on arno below). |
||
620 | <BLOCKQUOTE><PRE><B>node5></B> iperf -c 224.0.67.67 -u --ttl 5 -t 5 |
||
621 | ------------------------------------------------------------ |
||
622 | Client connecting to 224.0.67.67, UDP port 5001 |
||
623 | Sending 1470 byte datagrams |
||
624 | Setting multicast TTL to 5 |
||
625 | UDP buffer size: 32.0 KByte (default) |
||
626 | ------------------------------------------------------------ |
||
627 | [ 3] local <IP Addr node5> port 1025 connected with 224.0.67.67 port 5001 |
||
628 | [ ID] Interval Transfer Bandwidth |
||
629 | [ 3] 0.0- 5.0 sec 642 KBytes 1.0 Mbits/sec |
||
630 | [ 3] Sent 447 datagrams |
||
631 | |||
632 | <B>node5></B> iperf -s -u -B 224.0.67.67 -i 1 |
||
633 | ------------------------------------------------------------ |
||
634 | Server listening on UDP port 5001 |
||
635 | Binding to local address 224.0.67.67 |
||
636 | Joining multicast group 224.0.67.67 |
||
637 | Receiving 1470 byte datagrams |
||
638 | UDP buffer size: 32.0 KByte (default) |
||
639 | ------------------------------------------------------------ |
||
640 | [ 3] local 224.0.67.67 port 5001 connected with <IP Addr node5> port 1025 |
||
641 | [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams |
||
642 | [ 3] 0.0- 1.0 sec 131 KBytes 1.0 Mbits/sec 0.007 ms 0/ 91 (0%) |
||
643 | [ 3] 1.0- 2.0 sec 128 KBytes 1.0 Mbits/sec 0.008 ms 0/ 89 (0%) |
||
644 | [ 3] 2.0- 3.0 sec 128 KBytes 1.0 Mbits/sec 0.010 ms 0/ 89 (0%) |
||
645 | [ 3] 3.0- 4.0 sec 128 KBytes 1.0 Mbits/sec 0.013 ms 0/ 89 (0%) |
||
646 | [ 3] 4.0- 5.0 sec 128 KBytes 1.0 Mbits/sec 0.008 ms 0/ 89 (0%) |
||
647 | [ 3] 0.0- 5.0 sec 642 KBytes 1.0 Mbits/sec 0.008 ms 0/ 447 (0%) |
||
648 | |||
649 | <B>node6></B> iperf -s -u -B 224.0.67.67 -i 1 |
||
650 | ------------------------------------------------------------ |
||
651 | Server listening on UDP port 5001 |
||
652 | Binding to local address 224.0.67.67 |
||
653 | Joining multicast group 224.0.67.67 |
||
654 | Receiving 1470 byte datagrams |
||
655 | UDP buffer size: 60.0 KByte (default) |
||
656 | ------------------------------------------------------------ |
||
657 | [ 3] local 224.0.67.67 port 5001 connected with <IP Addr node5> port 1025 |
||
658 | [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams |
||
659 | [ 3] 0.0- 1.0 sec 129 KBytes 1.0 Mbits/sec 0.778 ms 61/ 151 (40%) |
||
660 | [ 3] 1.0- 2.0 sec 128 KBytes 1.0 Mbits/sec 0.236 ms 0/ 89 (0%) |
||
661 | [ 3] 2.0- 3.0 sec 128 KBytes 1.0 Mbits/sec 0.264 ms 0/ 89 (0%) |
||
662 | [ 3] 3.0- 4.0 sec 128 KBytes 1.0 Mbits/sec 0.248 ms 0/ 89 (0%) |
||
663 | [ 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> |
||
664 | <P><A name=ipv6></A> |
||
665 | <DL> |
||
666 | <DT><B><FONT size=+2>IPv6 Mode</FONT></B> |
||
667 | <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. |
||
668 | <P>Server side:<BR><FONT color=#000099> $ iperf -s -V</FONT> |
||
669 | <P>Client side:<BR><FONT color=#000099>$ iperf -c <Server IPv6 Address> -V </FONT> |
||
670 | <P>Note: Iperf version 1.6.2 and eariler require a IPv6 address to be explicitly bound |
||
671 | with the <A HREF="#bind">-B</A> option for the server.</P></DD></DL> |
||
672 | <HR> |
||
673 | <P><A name=repmode></A> |
||
674 | <DL> |
||
675 | <DT><B><FONT size=+2>Using Representative Streams to measure |
||
676 | bandwidth</FONT></B> |
||
677 | <DD>Use the -F or -I option. If you want to test how your network performs |
||
678 | with compressed / uncompressed streams, just create representative streams and |
||
679 | use the -F option to test it. This is usually due to the link layer |
||
680 | compressing data. |
||
681 | <P>The -F option is for file input.<BR>The -I option is for input from stdin. |
||
682 | <P>E.g. <BR>Client: $ <FONT color=#000099> iperf -c <server address> -F <file-name><BR></FONT> |
||
683 | <BR>Client: $ <FONT color=#000099> iperf -c <server address> -I </FONT></P></DD></DL> |
||
684 | <P><A name=daemon></A> |
||
685 | <HR> |
||
686 | <DL> |
||
687 | <DT><B><FONT size=+2>Running the server as a daemon</FONT></B> |
||
688 | <DD>Use the -D command line option to run the server as a daemon. Redirect the |
||
689 | output to a file.<BR>E.g. <FONT color=#000099>iperf -s -D > |
||
690 | iperfLog</FONT>. <FONT color=#000000>This will have the Iperf Server running |
||
691 | as a daemon and the server messages will be logged in the file iperfLog. |
||
692 | </DD></DL> |
||
693 | <HR> |
||
694 | <P><A name=service></A> |
||
695 | <DL> |
||
696 | <DT><B><FONT size=+2>Using Iperf as a Service under Win32</FONT></B> |
||
697 | <DD>There are three options for Win32: |
||
698 | <P> |
||
699 | <DL> |
||
700 | <DT>-o outputfilename |
||
701 | <DD>output the messages into the specified file |
||
702 | <DT>-s -D |
||
703 | <DD>install Iperf as a service and run it |
||
704 | <DT>-s -R |
||
705 | <DD>uninstall the Iperf service </DD></DL> |
||
706 | <P>Examples: |
||
707 | <DL> |
||
708 | <DT><FONT color=#3366ff>iperf -s -D -o iperflog.txt</FONT> |
||
709 | <DD>will install the Iperf service and run it. Messages will be reported |
||
710 | into "%windir%\system32\iperflog.txt" |
||
711 | <P></P> |
||
712 | <DT><FONT color=#3366ff>iperf -s -R</FONT> |
||
713 | <DD>will uninstall the Iperf service if it is installed. |
||
714 | <P>Note: If you stop want to restart the Iperf service after having killed |
||
715 | it with the Microsoft Management Console or the Windows Task Manager, make |
||
716 | sure to use the proper OPTION in the service properties dialog. |
||
717 | </P></DD></DL></DD></DL> |
||
718 | <HR> |
||
719 | <!--<P><A name=multicast></A> |
||
720 | <DL> |
||
721 | <DT><B><FONT size=+2>Running the multicast server and client</FONT></B> |
||
722 | <DD>Use the -B option while starting the server to bind it to a multicast |
||
723 | address.<BR>E.g. :-<FONT color=#3366ff>iperf -s -u -B 224.0.55.55</FONT>. |
||
724 | |||
725 | <P>This will have the Iperf server listening for datagrams (-u) for the |
||
726 | address 224.0.55.55(-B 224.0.55.55). |
||
727 | <P>Now, start a client sending packets to this multicast address. |
||
728 | <P>E.g. : <FONT color=#3366ff>iperf -c 224.0.55.55 -u</FONT>. |
||
729 | This will have a UDP client (-u) sending to the multicast address |
||
730 | 224.0.55.55(-c 224.0.55.55). |
||
731 | <P><FONT color=#000000>Start multiple clients or servers as explained above, |
||
732 | sending data to the same multicast server. (If you have multiple servers |
||
733 | listening on the multicast address, each of the servers will be getting the data) |
||
734 | </P></DD></DL> |
||
735 | <HR>--> |
||
736 | <!--<A name=adaptive></A> |
||
737 | <DL> |
||
738 | <DT><B><FONT size=+2>Adaptive window sizes</FONT></B> |
||
739 | <DD>Use the -W option on the client to run the client with the adaptive window |
||
740 | size. Ensure that the server window size is fairly big for this |
||
741 | option.<BR>E.g.. If the server TCP window size is 8KB, it does not help having |
||
742 | a client TCP window size of 256KB.<BR>256KB Server TCP Window Size should |
||
743 | suffice for most high bandwidth networks. |
||
744 | <P>Client changes the TCP window size using a binary exponential |
||
745 | algorithm. This means that you may notice that TCP window size suggested may |
||
746 | vary according to the traffic in the network, Iperf will suggest the best |
||
747 | window size for the current network scenario. |
||
748 | </DL> |
||
749 | <HR width="100%"> |
||
750 | --><P><!-- ----- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- --> |
||
751 | <CENTER> |
||
752 | <P>Copyright 1999,2000,2001,2002,2003,2004 <BR>The Board of Trustees of the University of |
||
753 | Illinois <BR>All rights reserved <BR>See <A |
||
754 | href="ui_license.html">UI License</A> for |
||
755 | complete details.</CENTER> |
||
756 | </BODY> |
||
757 | </HTML> |
||
758 |