What Is Iperf?
Iperf is a tool to measure maximum TCP bandwidth, allowing the tuning of various parameters and UDP characteristics. Iperf reports bandwidth, delay jitter, datagram loss.
Features
TCP
Measure bandwidth
Report MSS/MTU size and observed read sizes.
Support for TCP window size via socket buffers.
Multi-threaded if pthreads or Win32 threads are available. Client and server can have multiple simultaneous connections.
UDP
Client can create UDP streams of specified bandwidth.
Measure packet loss
Measure delay jitter
Multicast capable
Multi-threaded if pthreads are available. Client and server can have multiple simultaneous connections. (This doesn't work in Windows.)
Where appropriate, options can be specified with K (kilo-) and M (mega-) suffices. So 128K instead of 131072 bytes.
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.
Server handles multiple connections, rather than quitting after a single test.
Print periodic, intermediate bandwidth, jitter, and loss reports at specified intervals.
Run the server as a daemon
Run the server as a Windows NT Service
Use representative streams to test out how link layer compression affects your achievable bandwidth.
Application
Ipref can download from here.
Tuning a TCP Connection
The primary goal of Ipref 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.
Note that many OSes and host 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).
Here is an example session :
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 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
node2> 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 15.7 Mbits/sec
node1> 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
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 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.
Here is an example sessions:
node2> 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%)
node1> 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
Reference :
Trackback(0)
 |
TrackBack URI for this entry
Subscribe to this comment's feed
Show/Hide comment form
apakah melalui nilai MTU yg dihasilkan dari perintah -m?
apakah setiap port memperngaruhi nilai dari monitoring ini?
mohon petunjuk sekali ...
terima kasih