OpenSS7
SS7 for the
Common Man
© Copyright 1997-2007 OpenSS7 Corporation All Rights Reserved.
Last modified: Wed, 05 Apr 2006 09:42:48 GMT
Home TopIndex FirstPrev Next LastMore Download Info FAQ Mail  Home -> Documentation -> Man Pages -> Manpage of IPERF
Quick Links

Download

SCTP

SIGTRAN

SS7

Hardware

STREAMS

Asterisk

Related

Package

Manual

FAQ

Man Pages

Applications

SS7 Stack

ISDN Stack

SIGTRAN Stack

VoIP Stack

MG Stack

SS7/ISDN Devices

IP Transport

Embedded Systems

OS

Documentation

FAQ

SIGTRAN

Design

Conformance

Performance

References

Man Pages

Manuals

Papers

Home

Overview

Status

Documentation

Resources

About

News

Manpage of IPERF

Description: Manual Page

Keywords: ss7 ss7/ip ss7 over ip ss7 mtp ss7 sccp ss7 tcap sigtran mtp sccp tcap openss7 acb56 linux telephony pstn linux telephony linux nebs linux compactpci


IPERF

Section: Linux User Commands (1)
Updated: Tue, 22 Aug 2017 05:31:31 GMT
Index Return to Main Contents

NAME

iperf - an internet protocol performance measurement and tuning tool

SYNOPSIS

iperf {-s|--server} [SERVER-OPTIONS] [CLIENT-SERVER-OPTIONS]
iperf {-c|--client} HOST [CLIENT-OPTIONS] [CLIENT-SERVER-OPTIONS]
iperf {-h|--help}
iperf {-v|--version}
iperf --copying

DESCRIPTION


This program iperf is the modified version of the original iperf program. This version allows that also a bandwidth for TCP may be specified. This can be done with the option -a which was not available in the original version.

iperf is an operational measurement tool for internet protocols with the following features:

For measuring sctp(7), iperf measures bandwidth, reports MSS/MTU size and observed read sizes, supports window size via socket buffers, and runs mutli-threaded if pthreads are available: client and server can have multiple simultaneous connections. For measuring tcp(7), iperf measures bandwidth, reports MSS/MTU size and observed read sizes, supports window size via socket buffers, and runs mutli-threaded if pthreads or Win32 threads are available: client and server can have multiple simultaneous connections. For measuring udp(7), iperf client can create UDP streams of specified bandwidth, measures packet loss, measures delay jitter, is multicast capable, and runs multi-threaded if pthreads are available: client and server can have multiple simultaneous connections (but not in Windows).

Where appropriate, options can be specified with K (kilo-) and M (mega-) suffices. So 128K instead of 131072 bytes. iperf can run for specified time, rather than a set amount of data to transfer; picks the best units for the size of data being reported; the server handles multiple connections, rather than quitting after a single test; prints periodic, intermediate bandwidth, jitter, and loss reports at specified intervals; runs the server as a daemon (check out Nettest for running it as a secure daemon); and uses representative streams to test out how link layer compression affects your achievable bandwidth.

ARGUMENTS

None.

OPTIONS

iperf runs in two modes (client or server) and measures one of three internet protocols (udp(7), tcp(7) or sctp(7)). Client mode is specified using the -c or --client option detailed below. Server mode is specified using the -s or --server option detail below. Default operation is for TCP. To specify operation for UDP, use the -u or --udp option. To specify operation for sctp(7), use the -z or --sctp option. Additional options are described below.

Modes

-s,--server
Specifies server mode operation. In server mode, the server listens on a specific PORT for client connections.
-c,--client[HOST]
Specifies client mode of operation. In client mode, the client connects to the specified HOST at which the server mode iperf should be running.
-h,--help
Displays usage information an exits.
-v,--version
Displays version information and exits.
--copying
Displays copyright and permissions information and exits.

Server Options

The following SERVER-OPTIONS are only applicable to server operation:

-1,--singleclient
Specifies that the server should accept only a single client at a time. The default is to accept and report all clients simultaneously. Also specified by the environment variable IPERF_SINGLECLIENT.
-D,--daemon
Runs the server in daemon mode. iperf will close standard input, output and error, detach itself from the controlling terminal and run in the background. The default behavior without this option specified is to run in the foreground.
-c,--client HOST
In server mode, limit the clients that can connect to the server to HOST. Also specified by the environment variable IPERF_CLIENT.
-P,--parallel COUNT
Specifies the number of connections handled by the server before closing. The default is zero (0), indicating that the number connections is unlimited. Also specified by the environment variable IPERF_PARALLEL.
-U,--single_udp
Specifies that the UDP server execute single threaded. Normally the UDP server will be multithreaded where possible. Also specified by the environment variable IPERF_SINGLE_UDP.

Client Options

The following CLIENT-OPTIONS are only applicable to client operation:

-b,--bandwidthBANDWIDTH[KM]
Specifies the UDP bandwidth (in [kM]bits per second) at which to send. This is only meaningful for UDP operation (see option -u). The default is 1 Mbit/sec. Also specified by the environment variable IPERF_BANDWIDTH.
-d,--dualtest
Specifies that iperf should be run in dual testing mode. This will cause the server to connect back to the client on the port specified with the -L option (or defaults to the port on which the client connected to the server). This is done immediately, therefore running the tests simultaneously. If you want an alternate test, see option -r. Also specified by the environment variable IPERF_DUALTEST.
-n,--numBUFFERS[KM]
Specifies the number of BUFFERS to transmit. Normally, iperf sends for 10 seconds. The -n option overrides this behavior and sends an array of LENGTH bytes, BUFFERS times, no matter how long it takes. See also the -l and -t options. Also specified by the environment variable IPERF_NUM.
-r,--tradeoff
Run the iperf tradeoff testing mode. This will cause the server to connect back to the client on the port specified with the -L option (or defaults to the port on which the client connected to the server). This is dones following the client connection termination, therefore running the tests alternating. If you want a simultaneous test, try option -d. Also specified by the environment variable IPERF_TRADEOFF.
-t,--timeDURATION
Specifies the DURATION in seconds for which to transmit. iperf normally works by repeatedly sending an array of LENGTH bytes for DURATION seconds. The default is 10 seconds. See also the -l and -n options. Also specified by the environment variable IPERF_TIME.
-F,--file_inputFILENAME
Specifies a representative stream to measure bandwidth. The data for transmission will be read from FILENAME.
-I,--stdin_input
Specifies a representative stream to measure bandwidth. The data for transmission will be read from stdin.
-L,--listenport
Specifies the port that the server will connect back to the client on (see -d and -r options). It defaults to the port used to connect to the server from the client. Also specified by the environment variable IPERF_LISTENPORT.
-P,--parallelNUMBER
Specifies the number of simultaneous connections to make to the server. Default is 1. Requires thread support on both the client and server. Also specified by the environment variable IPERF_PARALLEL.
-S,--tosTOS
Specifies 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[1] are:

IPTOS_LOWDELAYminimize delay0x10
IPTOS_THROUGHPUTminimize throughput0x08
IPTOS_RELIABILITYmaximize reliability0x04
IPTOS_LOWCOSTminimize cost0x02

Also specified by the environment variable IPERF_TOS.

-T,--ttlTTL
Specifies the time-to-live for outgoing multicast packets. This is essentially the number of router hops that the packet will traverse, and is also used for scoping. The default time-to-live is 1, or link-local. Also specified by the environment variable IPERF_TTL.
-W,--suggest_win_size
The -W option is not available in this release. Also specified by the environment variable IPERF_SUGGEST_WIN_SIZE.

Client/Server Options

The following CLIENT-SERVER-OPTIONS are applicable to both client and server operation:

-f,--format[bkmaBKMA]
Specifies the format in which to print bandwidth information. Supported formats are:

bbits/secBbytes/sec
kkbits/secKkbytes/sec
mMbits/secMMbytes/sec
gGbits/secGGbytes/sec
aadaptive bits/secAadaptive bytes/sec

The adaptive formats choose between kilo- and mega- as appropriate. Fields other than bandwidth always print bytes, but otherwise follow the requested format. The default format is 'a'. 'k', 'm' and 'g' correspond to multipliers of 10^3, 10^6, 10^9. 'K', 'M' and 'G' corresponds to multipliers of 2^10, 2^20 and 2^30.

Also specified by the environment variable IPERF_FORMAT.

-i,--interval INTERVAL
Specifies the time interval (in seconds) between periodic bandwidth, jitter and loss reports. If non-zero, a report is made every interval seconds of the bandwidth since the last report. If zero, no periodic reports are printed. The default is zero (do no print periodic reports). Also specified by the environment variable IPERF_INTERVAL.
-l,--len LENGTH[KM]
Specifies the length (in bytes) of buffers to read or write. iperf works by writing an array of LENGTH bytes a number of iterations. The default is 8 KB for TCP, 8 KB for SCTP, and 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 IP fragmentation. See also the -n and -t options. Also specified by the environment variable IPERF_LEN.
-m,--print_mss
Print the reported SCTP or TCP MSS size (via the SCTP_MAXSEG or TCP_MAXSEG option) and the observed read sizes which often correlate with the MSS. The MSS is usually the MTU minus 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 operating systems, but the read sizes may still indicate the MSS. Also specified by the environment variable IPERF_PRINT_MSS.
-p,--port PORT
The server PORT number upon which the server will listen, or the PORT number to which the client will connect. This should be specified the same for both client and server. The default is 5001, the same as ttcp. Also specified by the environment variable IPERF_PORT.
-q,--seqpacket
Use a SOCK_SEQPACKET socket for SCTP rather than a TCP compatible SOCK_STREAM socket. This is only meaningful when SCTP is specified (see the -z option). SOCK_SEQPACKET produces SCTP behavior more closely resembling UDP; whereas, SOCK_STREAM produces SCTP behavior more closely resembling TCP. Also specified by the environment variable IPERF_SEQPACKET.

This option is an OpenSS7 SCTP-specific modification to iperf.

-u,--udp
Use UDP rather than TCP or SCTP. See also the -b option. Also specified by the environment variable IPERF_UDP.
-x,--reportexclude EXCLUDE
Specifies which reports to EXCLUDE. EXCLUDE can be one ore more of the following characters:

sexclude set reports
cexclude connection reports
dexclude data reports
vexclude server reports
mexclude multiple reports

Also specified by the environment variable IPERF_REPORTEXCLUDE.

-y,--reportstyle STYLE
Specifies the STYLE of the reports. STYLE can be one or more of the following characters:

creports in CSV style

Also specified by the environment variable IPERF_REPORTSTYLE.

-w,--window SIZE[KM]
Specifies the socket buffer sizes. For SCTP and TCP, this sets the window size. For UDP, this is just the size of the buffer into which datagrams are received, and so limits the largest receivable datagram size. Also specified by the environment variable TCP_WINDOW_SIZE.
-z,--sctp
Use SCTP rather than TCP or UDP. See also the -q option. Also specified by the environment variable IPERF_SCTP.

This option is an OpenSS7 SCTP-specific modification to iperf.

-B,--bind HOST
Specify the HOST or ip address to which to bind. This is the local interface in both client and server mode.

For sctp(7) operation, this restricts a multihomed association to a single local IP address. When not specified, all outgoing interfaces will be used on connect(2) for clients, and all incoming interfaces will be automaticlly selected on accept(2) for servers.

For tcp(7) operation, this is useful on a multihomed host, which has multiple network interfaces, to specify the local interface address. When not specified, the outgoing interface will be automatically selected on connect(2) for clients, and the incoming interface will be automatically selected on accept(2) for servers.

For udp(7) operation, this can be 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 -T option. Also specified by the environment variable IPERF_BIND.

-C,--compatibility
Specifies that compatibility with older versions of iperf should be provided. This mode is not required for interoperability between different versions of client and server, however, 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. Also specified by the environment variable IPERF_COMPAT.
-M,--mss SIZE[KM]
Specifies the SCTP or TCP maximum segment size (MSS) in [KM]bytes via the SCTP_MAXSEG or TCP_MAXSEG option. The MSS is usually the MTU minus 40 bytes for the TCP/IP header. For ethernet, the MSS is 1460 bytes (1500 byte MTU). This option is not implemented on many operating systems. Also specified by the environment variable IPERF_MSS.
-N,--nodelay
Set the SCTP or TCP no delay option, disabling Nagle's algorithm. Normally this is only disabled for interactive applications like telnet. Also specified by the environment variable IPERF_NODELAY.
-V,--ipv6_domain
Bind to an IPv6 address.

Server side:
$ iperf -s -V

Client side:
$ iperf -c <Server IPv6 Address> -V

Note: On version 1.6.3 and later a specific IPv6 Address does not need to be bound with the -B option, previous 1.6 versions do. Also on most operating systems using this option will also respond to IPv4 clients using IPv4 mapped addresses.

Also specified by the environment variable IPERF_IPV6_DOMAIN.

USAGE

iperf is used for testing throughput and performance under a number of factors for internet protocols: UDP, TCP and SCTP. The effect of the options differ somewhat based on the protocol under test. These effects are detailed in the following subsections:

Tuning an SCTP Connection

This version of iperf has been modified to work with Stream Control Transmission Protocol (SCTP) as described in RFC 2960[2]. Although most of the discussion under TuningaTCPConnection , below, also applies to SCTP, one of the most siginificant factors affecting SCTP performance for the OpenSS7 SCTP implementation is packet mode and the number of interfaces in a multihomed host.

There are two packet modes for SCTP (see sctp(7)):

SOCK_STREAM
This is the default mode of operation for SCTP under iperf.

The stream mode SCTP socket is intended as a drop in compatible replacement for TCP sockets. These sockets do not respect record boundaries, and transmit packets in a single SCTP stream. Alhtough SCTP has a few more packet overheads than TCP, performance of SCTP in SOCK_STREAM mode is closely comparable to TCP when a single interface is used. However, when multiple interfaces are used, OpenSS7 SCTP exhibits multiplicative increases in throughput because the bandwidth of multiple interfaces can be used up to the maximum throughput of the underlying network.

SOCK_SEQPACKET
This packet mode can be selected using the -q or --seqpacket option under iperf.

The sequenced packet mode SCTP socket is intended to utilized the features of the SCTP protocol. These sockets respect record boundaries, transmit packets on multiple SCTP streams, and supports both sequenced and unsequenced delivery. Performance of SCTP in SOCK_SEQPACKET mode is closely comparable to UDP when a single interface is used. However, when multiple interfaces are used, OpenSS7 SCTP exhibits multiplicative increases in throughput because the bandwidth of multiple interfaces can be used up to the maximum throughput of the underlying network.

Controlling the number of interfaces on a multihomed host utilized by an SCTP association under iperf is controlled using the -B or --bind option. When the -B option is not specified, the server or client will bind to all available interface addresses and will form an association with all of them. The server or client will then transmit on multiple interfaces and multiplicative throughputs will be experienced. When the -B option is specified, the server or client will bind to only the specified interface address and will form an association with only the specified interface. The server or client will then transmit on a single interface and comparable throughputs to TCP or UDP will be experienced.

Some examples of test runs on a low-latency, low-error, high-speed LAN connection with multiple interfaces are shown below under EXAMPLES .

Tuning a TCP Connection

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 sending will be idle at times and get poor performance. The theoretical value to use for the TCP window size is the bandwidth delay product,

bottleneck bandwidth x round trip time

In the examples, see section EXAMPLES , the bottleneck link is a 45 Mbit/sec DS3 link and the round trip time measured with ping(8) is 42 ms. The bandwidth delay product is:

45 Mbit/sec x 42 ms
= (45E06) x (42E-03)
= 1890000 bits
= 230 KByte

That is the starting point for figuring the best window size; setting it higher or lower may produce better results. In the example, below, buffer sizes over 130K did not improve the performance, despite the bandwidth delay product of 230K.

Note that many Operating Systems and hosts have upper limits on the TCP window size. These may be as low as 64 kilobytes, or as high as several megabytes. iperf tires 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 list[3] detailing how to change the default and maximum window sizes for various operating systems. For more information on TCP window sizes, see the User'sGuideforTCPWindows .[4]

Tuning a UDP Connection

iperf creates a constant bit rate UDP stream. This is a very artificial stream, similar to voice communication but not much else.

You will want to adjust the datagram size (-l) to the size your application uses.

The service 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.

Jitter calculations are continuously computed by the server, as specified by RTP in RFC 1889[5]. The client records a 64 bit second/microsecond timestamp in the packet. The server computes the relative transmit time as (server's receive time minus client's send time). The client's and server's clocks do not need to by synchornized; any difference is subtracted out in the jitter calculation. Jitter is the smoothed mean of differences between consecutive transit times.

ENVIRONMENT VARIABLES

Most of the options can also be set using environment variables. The environment variable TCP_WINDOW_SIZE sets the TCP window size, whereas other options may be set using the environment variable named IPERF_[long option name] as follows:

IPERF_BANDWIDTH
Same as option -b or --bandwidth.
IPERF_BIND
Same as option -B or --bind.
IPERF_CLIENT
Same as option -c or --client.
IPERF_COMPAT
Same as option -C or --compatibility.
IPERF_DUALTEST
Same as option -d or --dualtest.
IPERF_FILE_INPUT
Same as option -F or --file_input.
IPERF_FORMAT
Same as option -f or --format.
IPERF_INTERVAL
Same as option -i or --interval.
IPERF_IPV6_DOMAIN
Same as option -V or --ipv6_domain.
IPERF_LEN
Same as option -l or --len.
IPERF_LISTENPORT
Same as option -L or --listenport.
IPERF_MSS
Same as option -M or --mss.
IPERF_NODELAY
Same as option -N or --nodelay.
IPERF_NUM
Same as option -n or --num.
IPERF_PARALLEL
Same as option -P or --parallel.
IPERF_PORT
Same as option -p or --port.
IPERF_PRINT_MSS
Same as option -m or --print_mss.
IPERF_REPORTEXCLUDE
Same as option -x or --reportexclude.
IPERF_REPORTSTYLE
Same as option -y or --reportstyle.
IPERF_SCTP
Same as option -z or --sctp.
IPERF_SEQPACKET
Same as option -q or --seqpacket.
IPERF_SERVER
Same as option -s or --server.
IPERF_SINGLECLIENT
Same as option -1 or --singleclient.
IPERF_SINGLE_UDP
Same as option -U or --single_udp.
IPERF_STDIN_INPUT
Same as option -I or --stdin_input.
IPERF_SUGGEST_WIN_SIZE
Same as option -W or --suggest_win_size.
IPERF_TIME
Same as option -t or --time.
IPERF_TOS
Same as option -S or --tos.
IPERF_TRADEOFF
Same as option -r or --tradeoff.
IPERF_TTL
Same as option -T or --ttl.
IPERF_UDP
Same as option -u or --udp.
TCP_WINDOW_SIZE
Same as option -w or --window.

EXAMPLES

Tuning an SCTP Connection

Tuning a TCP Connection

Here is an example session, between node1 in Illinois and node2 in North Carolina. There are connected via tht vBNS backbone and a 45 Mbit/sec DS3 link. Note we improve bandwidth performance by a factor of 3 using proper TCP window size. Use the adaptive window sizes feature on platforms that allow setting window sizes in the granularity of bytes.

Following is an example of performance from the default TCP window size:

node2> 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   5.2 Mbits/sec
node1> iperf -c node2
------------------------------------------------------------
Client connecting to node2, 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

Following is an example of performance using an increated TCP window size:

node2> iperf -s -w 130k
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size:  130 KByte
------------------------------------------------------------
[  4] local <IP Addr node2> port 5001 connected with <IP Addr node1> port 2530
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.1 sec  19.7 MBytes   15.7 Mbits/sec
node1> iperf -c node2 -w 130k
------------------------------------------------------------
Client connecting to node2, TCP port 5001
TCP window size:  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

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 operating system's TCP implementation has bugs, or the network itself has deficientices. See above for TCP window sizes; otherwise diagnosing which is somewhat difficult. If iperf is compiled with pthreads(3), a single client and server can test this, otherwise, set up multiple clients and servers on different ports. Following is 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:

node2> 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  16.5 Mbits/sec
[  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  16.7 Mbits/sec
[  4]  0.0-10.3 sec  12.0 MBytes   9.4 Mbits/sec
node1> ./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
node1> 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

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 list[6] detailing what operating systems 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.

node3> 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] MSS size 1448 bytes (MTU 1500 bytes, ethernet)
[  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%)

Here is a host that doesn't support Path MTU Discovery. It will only send and receive small 576 byte packets.

node4> 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
WARNING: Path MTU Discovery may not be enabled.
[  4] MSS size 536 bytes (MTU 576 bytes, minimum)
[  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%)

iperf supports other tuning options, which were added for exceptional network situations lik HIPPI-to-HIPPI over ATM.

Tuning a UDP Connection

DIAGNOSTICS

When successful, iperf returns zero (0). When unsuccessful, iperf returns a non-zero value and prints a diagnostic message. A return value of 1 indicates that there was a fatal error. A return value of 2 indicates that there was an option syntax error.

SEE ALSO

sctp(7), tcp(7), udp(7), ip(7), connect(2), accept(2), ping(8), pthreads(3), netperf(1).

BUGS

iperf has no known bugs.

Report bugs related to the SCTP extensions to <bugs@openss7.org>.

Report bugs related to iperf other than SCTP extensions to <dast@nlanr.net>.

COMPATIBILITY

iperf modified for SCTP operation is compatible for TCP and UDP operation with unmodified versions of iperf.

CONFORMANCE

There are no formal specifications for conformance of iperf.

HISTORY

iperf is a replacement modified version of the University of Illinois iperf package. The first version modified by OpenSS7 for use with OpenSS7 Linux Native Sockets SCTP was iperf version 1.6.5. This is a modification of iperf version 2.0.1. Modifications are consistent with those made to version 1.6.5.

REFERENCES

[1]
RFC 1349, Type of Service in the Internet Protocol Suite, July 1992, Philip Almquist, ed., The Internet Society. (Obsoleted by RFC 2474) (Updates RFC 1248, RFC 1247, RFC 1195, RFC 1123, RFC 1122, RFC 1060, RFC 0791) (Status: PROPOSED STANDARD) <http://www.ietf.org/rfc/rfc1349.txt>
[2]
RFC 2960, Stream Control Transmission Protocol (SCTP), October 2000, Randall R. Stewart, ed., The Internet Society. (Obsoleted by RFC 4960) (Updated by RFC 3309) (Status: PROPOSED STANDARD) <http://www.ietf.org/rfc/rfc2960.txt>
[3]
PSC List of TCP Window Sizes. <http://www.psc.edu/networking/perf_tune.html>
[4]
User's Guide for TCP Windows. <http://dast.nlanr.net/Guides/GettingStarted/TCP_window_size.html>
[5]
RFC 1889, RTP: A Transport Protocol for Real-Time Application, January 1996, Henry Shulzrinne, ed., The Internet Society. <http://www.ietf.org/rfc/rfc1889.txt>
[6]
Path MTU Discovery. <http://www.psc.edu/networking/perf_tune.html>

TRADEMARKS

OpenSS7tm
is a trademark of OpenSS7 Corporation.
Linux®
is a registered trademark of Linus Torvalds.
UNIX®
is a registered trademark of The Open Group.
Solaris®
is a registered trademark of Sun Microsystems.

Other trademarks are the property of their respective owners.

IDENTIFICATION

The OpenSS7 Project: Package OpenSS7 version 0.9.2 released Tue, 22 Aug 2017 05:31:31 GMT.

Copyright©1997-2008OpenSS7 Corp.

Copyright©1999-2004The Board of Trustees of the University of Illinois
All Rights Reserved.
(See roff source for permission notice.)



Index

NAME
SYNOPSIS
DESCRIPTION
ARGUMENTS
OPTIONS
Modes
Server Options
Client Options
Client/Server Options
USAGE
Tuning an SCTP Connection
Tuning a TCP Connection
Tuning a UDP Connection
ENVIRONMENT VARIABLES
EXAMPLES
Tuning an SCTP Connection
Tuning a TCP Connection
Tuning a UDP Connection
DIAGNOSTICS
SEE ALSO
BUGS
COMPATIBILITY
CONFORMANCE
HISTORY
REFERENCES
TRADEMARKS
IDENTIFICATION

This document was created by man2html, using the manual pages.
Time: 05:31:31 GMT, August 22, 2017
OpenSS7
SS7 for the
Common Man
Home TopIndex FirstPrev Next LastMore Download Info FAQ Mail  Home -> Documentation -> Man Pages -> Manpage of IPERF
Last modified: Wed, 05 Apr 2006 09:42:48 GMT
© Copyright 1997-2007 OpenSS7 Corporation All Rights Reserved.