By default, the Iperf client connects to the Iperf server on the TCP port 5001 and the bandwidth displayed by Iperf is the bandwidth from the client to the server.
If you want to use UDP tests, use the -u argument.
The -d and -r Iperf client arguments measure the bi-directional bandwidths. (See further on this tutorial)

Client side:

#iperf -c 10.1.1.1
————————————————————
Client connecting to 10.1.1.1, TCP port 5001
TCP window size: 16384 Byte (default)
————————————————————
[ 3] local 10.6.2.5 port 33453 connected with 10.1.1.1 port 5001
[ 3] 0.0-10.2 sec 1.26 MBytes 1.05 Mbits/sec

Server side:

#iperf -s
————————————————————
Server listening on TCP port 5001
TCP window size: 8.00 KByte (default)
————————————————————
[852] local 10.1.1.1 port 5001 connected with 10.6.2.5 port 33453
[ ID] Interval Transfer Bandwidth
[852] 0.0-10.6 sec 1.26 MBytes 1.03 Mbits/sec

Data formatting: (-f argument)

The -f argument can display the results in the desired format: bits(b), bytes(B), kilobits(k), kilobytes(K), megabits(m), megabytes(M), gigabits(g) or gigabytes(G).
Generally the bandwidth measures are displayed in bits (or Kilobits, etc …) and an amount of data is displayed in bytes (or Kilobytes, etc …).
As a reminder, 1 byte is equal to 8 bits and, in the computer science world, 1 kilo is equal to 1024 (2^10).
For example: 100’000’000 bytes is not equal to 100 Mbytes but to 100’000’000/1024/1024 = 95.37 Mbytes.

Client side:

#iperf -c 10.1.1.1 -f b
————————————————————
Client connecting to 10.1.1.1, TCP port 5001
TCP window size: 16384 Byte (default)
————————————————————
[ 3] local 10.6.2.5 port 54953 connected with 10.1.1.1 port 5001
[ 3] 0.0-10.2 sec 1359872 Bytes 1064272 bits/sec

Server side:

#iperf -s
————————————————————
Server listening on TCP port 5001
TCP window size: 8.00 KByte (default)
————————————————————
[852] local 10.1.1.1 port 5001 connected with 10.6.2.5 port 33453
[ ID] Interval Transfer Bandwidth
[852] 0.0-10.6 sec 920 KBytes 711 Kbits/sec

Top of the page

Bi-directional bandwidth measurement: (-r argument)

The Iperf server connects back to the client allowing the bi-directional bandwidth measurement. By default, only the bandwidth from the client to the server is measured.
If you want to measure the bi-directional bandwidth simultaneously, use the -d keyword. (See next test.)

Client side:

#iperf -c 10.1.1.1 -r
————————————————————
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
————————————————————
————————————————————
Client connecting to 10.1.1.1, TCP port 5001
TCP window size: 16.0 KByte (default)
————————————————————
[ 5] local 10.6.2.5 port 35726 connected with 10.1.1.1 port 5001
[ 5] 0.0-10.0 sec 1.12 MBytes 936 Kbits/sec
[ 4] local 10.6.2.5 port 5001 connected with 10.1.1.1 port 1640
[ 4] 0.0-10.1 sec 74.2 MBytes 61.7 Mbits/sec

Server side:

#iperf -s
————————————————————
Server listening on TCP port 5001
TCP window size: 8.00 KByte (default)
————————————————————
[852] local 10.1.1.1 port 5001 connected with 10.6.2.5 port 54355
[ ID] Interval Transfer Bandwidth
[852] 0.0-10.1 sec 1.15 MBytes 956 Kbits/sec
————————————————————
Client connecting to 10.6.2.5, TCP port 5001
TCP window size: 8.00 KByte (default)
————————————————————
[824] local 10.1.1.1 port 1646 connected with 10.6.2.5 port 5001
[ ID] Interval Transfer Bandwidth
[824] 0.0-10.0 sec 73.3 MBytes 61.4 Mbits/sec

Top of the page

Simultaneous bi-directional bandwidth measurement: (-d argument)
Also check the “Jperf” section.

To measure the bi-directional bandwidths simultaneousely, use the -d argument. If you want to test the bandwidths sequentially, use the -r argument (see previous test).
By default (ie: without the -r or -d arguments), only the bandwidth from the client to the server is measured.

Client side:

#iperf -c 10.1.1.1 -d
————————————————————
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
————————————————————
————————————————————
Client connecting to 10.1.1.1, TCP port 5001
TCP window size: 16.0 KByte (default)
————————————————————
[ 5] local 10.6.2.5 port 60270 connected with 10.1.1.1 port 5001
[ 4] local 10.6.2.5 port 5001 connected with 10.1.1.1 port 2643
[ 4] 0.0-10.0 sec 76.3 MBytes 63.9 Mbits/sec
[ 5] 0.0-10.1 sec 1.55 MBytes 1.29 Mbits/sec

Server side:

#iperf -s
————————————————————
Server listening on TCP port 5001
TCP window size: 8.00 KByte (default)
————————————————————
[852] local 10.1.1.1 port 5001 connected with 10.6.2.5 port 60270
————————————————————
Client connecting to 10.6.2.5, TCP port 5001
TCP window size: 8.00 KByte (default)
————————————————————
[800] local 10.1.1.1 port 2643 connected with 10.6.2.5 port 5001
[ ID] Interval Transfer Bandwidth
[800] 0.0-10.0 sec 76.3 MBytes 63.9 Mbits/sec
[852] 0.0-10.1 sec 1.55 MBytes 1.29 Mbits/sec

Top of the page

TCP Window size: (-w argument)

The TCP window size is the amount of data that can be buffered during a connection without a validation from the receiver.
It can be between 2 and 65,535 bytes.
On Linux systems, when specifying a TCP buffer size with the -w argument, the kernel allocates double as much as indicated.

Client side:

#iperf -c 10.1.1.1 -w 2000
WARNING: TCP window size set to 2000 bytes. A small window size
will give poor performance. See the Iperf documentation.
————————————————————
Client connecting to 10.1.1.1, TCP port 5001
TCP window size: 3.91 KByte (WARNING: requested 1.95 KByte)
————————————————————
[ 3] local 10.6.2.5 port 51400 connected with 10.1.1.1 port 5001
[ 3] 0.0-10.1 sec 704 KBytes 572 Kbits/sec

Server side:

#iperf -s -w 4000
————————————————————
Server listening on TCP port 5001
TCP window size: 3.91 KByte
————————————————————
[852] local 10.1.1.1 port 5001 connected with 10.6.2.5 port 51400
[ ID] Interval Transfer Bandwidth
[852] 0.0-10.1 sec 704 KBytes 570 Kbits/sec

Top of the page

Communication port (-p), timing (-t) and interval (-i):

The Iperf server communication port can be changed with the -p argument. It must be configured on the client and the server with the same value, default is TCP port 5001.
The -t argument specifies the test duration time in seconds, default is 10 secs.
The -i argument indicates the interval in seconds between periodic bandwidth reports.

Client side:

#iperf -c 10.1.1.1 -p 12000 -t 20 -i 2
————————————————————
Client connecting to 10.1.1.1, TCP port 12000
TCP window size: 16.0 KByte (default)
————————————————————
[ 3] local 10.6.2.5 port 58316 connected with 10.1.1.1 port 12000
[ 3] 0.0- 2.0 sec 224 KBytes 918 Kbits/sec
[ 3] 2.0- 4.0 sec 368 KBytes 1.51 Mbits/sec
[ 3] 4.0- 6.0 sec 704 KBytes 2.88 Mbits/sec
[ 3] 6.0- 8.0 sec 280 KBytes 1.15 Mbits/sec
[ 3] 8.0-10.0 sec 208 KBytes 852 Kbits/sec
[ 3] 10.0-12.0 sec 344 KBytes 1.41 Mbits/sec
[ 3] 12.0-14.0 sec 208 KBytes 852 Kbits/sec
[ 3] 14.0-16.0 sec 232 KBytes 950 Kbits/sec
[ 3] 16.0-18.0 sec 232 KBytes 950 Kbits/sec
[ 3] 18.0-20.0 sec 264 KBytes 1.08 Mbits/sec
[ 3] 0.0-20.1 sec 3.00 MBytes 1.25 Mbits/sec

Server side:

#iperf -s -p 12000
————————————————————
Server listening on TCP port 12000
TCP window size: 8.00 KByte (default)
————————————————————
[852] local 10.1.1.1 port 12000 connected with 10.6.2.5 port 58316
[ ID] Interval Transfer Bandwidth
[852] 0.0-20.1 sec 3.00 MBytes 1.25 Mbits/sec

Top of the page

UDP tests: (-u), bandwidth settings (-b)
Also check the “Jperf” section.

The UDP tests with the -u argument will give invaluable information about the jitter and the packet loss. If you don’t specify the -u argument, Iperf uses TCP.
To keep a good link quality, the packet loss should not go over 1 %. A high packet loss rate will generate a lot of TCP segment retransmissions which will affect the bandwidth.

The jitter is basically the latency variation and does not depend on the latency. You can have high response times and a very low jitter. The jitter value is particularly important on network links supporting voice over IP (VoIP) because a high jitter can break a call.
The -b argument allows the allocation if the desired bandwidth.

Client side:

#iperf -c 10.1.1.1 -u -b 10m
————————————————————
Client connecting to 10.1.1.1, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 108 KByte (default)
————————————————————
[ 3] local 10.6.2.5 port 32781 connected with 10.1.1.1 port 5001
[ 3] 0.0-10.0 sec 11.8 MBytes 9.89 Mbits/sec
[ 3] Sent 8409 datagrams
[ 3] Server Report:
[ 3] 0.0-10.0 sec 11.8 MBytes 9.86 Mbits/sec 2.617 ms 9/ 8409 (0.11%)

Server side:

#iperf -s -u -i 1
————————————————————
Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size: 8.00 KByte (default)
————————————————————
[904] local 10.1.1.1 port 5001 connected with 10.6.2.5 port 32781
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[904] 0.0- 1.0 sec 1.17 MBytes 9.84 Mbits/sec 1.830 ms 0/ 837 (0%)
[904] 1.0- 2.0 sec 1.18 MBytes 9.94 Mbits/sec 1.846 ms 5/ 850 (0.59%)
[904] 2.0- 3.0 sec 1.19 MBytes 9.98 Mbits/sec 1.802 ms 2/ 851 (0.24%)
[904] 3.0- 4.0 sec 1.19 MBytes 10.0 Mbits/sec 1.830 ms 0/ 850 (0%)
[904] 4.0- 5.0 sec 1.19 MBytes 9.98 Mbits/sec 1.846 ms 1/ 850 (0.12%)
[904] 5.0- 6.0 sec 1.19 MBytes 10.0 Mbits/sec 1.806 ms 0/ 851 (0%)
[904] 6.0- 7.0 sec 1.06 MBytes 8.87 Mbits/sec 1.803 ms 1/ 755 (0.13%)
[904] 7.0- 8.0 sec 1.19 MBytes 10.0 Mbits/sec 1.831 ms 0/ 850 (0%)
[904] 8.0- 9.0 sec 1.19 MBytes 10.0 Mbits/sec 1.841 ms 0/ 850 (0%)
[904] 9.0-10.0 sec 1.19 MBytes 10.0 Mbits/sec 1.801 ms 0/ 851 (0%)
[904] 0.0-10.0 sec 11.8 MBytes 9.86 Mbits/sec 2.618 ms 9/ 8409 (0.11%)

Top of the page

Maximum Segment Size (-m argument) display:

The Maximum Segment Size (MSS) is the largest amount of data, in bytes, that a computer can support in a single, unfragmented TCP segment.
It can be calculated as follows:
MSS = MTU – TCP & IP headers
The TCP & IP headers are equal to 40 bytes.
The MTU or Maximum Transmission Unit is the greatest amount of data that can be transferred in a frame.
Here are some default MTU size for different network topology:
Ethernet – 1500 bytes: used in a LAN.
PPPoE – 1492 bytes: used on ADSL links.
Token Ring (16Mb/sec) – 17914 bytes: old technology developed by IBM.
Dial-up – 576 bytes

Generally, a higher MTU (and MSS) brings higher bandwidth efficiency

Client side:

#iperf -c 10.1.1.1 -m
————————————————————
Client connecting to 10.1.1.1, TCP port 5001
TCP window size: 16.0 KByte (default)
————————————————————
[ 3] local 10.6.2.5 port 41532 connected with 10.1.1.1 port 5001
[ 3] 0.0-10.2 sec 1.27 MBytes 1.04 Mbits/sec
[ 3] MSS size 1448 bytes (MTU 1500 bytes, ethernet)

Here the MSS is not equal to 1500 – 40 but to 1500 – 40 – 12 (Timestamps option) = 1448

Server side:

#iperf -s
Top of the page

Maximum Segment Size (-M argument) settings:

Use the -M argument to change the MSS. (See the previous test for more explanations about the MSS)

#iperf -c 10.1.1.1 -M 1300 -m
WARNING: attempt to set TCP maximum segment size to 1300, but got 536
————————————————————
Client connecting to 10.1.1.1, TCP port 5001
TCP window size: 16.0 KByte (default)
————————————————————
[ 3] local 10.6.2.5 port 41533 connected with 10.1.1.1 port 5001
[ 3] 0.0-10.1 sec 4.29 MBytes 3.58 Mbits/sec
[ 3] MSS size 1288 bytes (MTU 1328 bytes, unknown interface)

Server side:

#iperf -s
Top of the page

Parallel tests (-P argument):

Use the -P argument to run parallel tests.

Client side:

#iperf -c 10.1.1.1 -P 2
————————————————————
Client connecting to 10.1.1.1, TCP port 5001
TCP window size: 16.0 KByte (default)
————————————————————
[ 3] local 10.6.2.5 port 41534 connected with 10.1.1.1 port 5001
[ 4] local 10.6.2.5 port 41535 connected with 10.1.1.1 port 5001
[ 4] 0.0-10.1 sec 1.35 MBytes 1.12 Mbits/sec
[ 3] 0.0-10.1 sec 1.35 MBytes 1.12 Mbits/sec
[SUM] 0.0-10.1 sec 2.70 MBytes 2.24 Mbits/sec

Server side:

#iperf -s
Top of the page

Iperf help:

#iperf -h
Usage: iperf [-s|-c host] [options]
iperf [-h|–help] [-v|–version]

Client/Server:
-f
-i
-l
-m
-p
-u
-w
-B
-C
-M
-N
-V –format
–interval
–len
–print_mss
–port
–udp
–window
–bind
–compatibility
–mss
–nodelay
–IPv6Version [kmKM]
#
#[KM]

#

#[KM]
“host”

#

format to report: Kbits, Mbits, KBytes, MBytes
seconds between periodic bandwidth reports
length of buffer to read or write (default 8 KB)
print TCP maximum segment size (MTU – TCP/IP header)
server port to listen on/connect to
use UDP rather than TCP
TCP window size (socket buffer size)
bind to “host”, an interface or multicast address
for use with older versions does not sent extra msgs
set TCP maximum segment size (MTU – 40 bytes)
set TCP no delay, disabling Nagle’s Algorithm
Set the domain to IPv6
Server specific:
-s
-U
-D –server
–single_udp
–daemon

run in server mode
run in single threaded UDP mode
run the server as a daemon
Client specific:
-b
-c
-d
-n
-r
-t
-F
-I
-L
-P
-T –bandwidth
–client
–dualtest
–num
–tradeoff
–time
–fileinput
–stdin
–listenport
–parallel
–ttl #[KM]
“host”

#[KM]

#
“name”

#
#
# for UDP, bandwidth to send at in bits/sec (default 1 Mbit/sec, implies -u)
run in client mode, connecting to “host”
Do a bidirectional test simultaneously
number of bytes to transmit (instead of -t)
Do a bidirectional test individually
time in seconds to transmit for (default 10 secs)
input the data to be transmitted from a file
input the data to be transmitted from stdin
port to recieve bidirectional tests back on
number of parallel client threads to run
time-to-live, for multicast (default 1)
Miscellaneous:
-h
-v –help
–version
print this message and quit
print version information and quit

Clap

Categories: Docker

Ajeet Raina

My name is Ajeet Singh Raina and I am an author of this blogging site. I am a Docker Captain, ARM Innovator & Docker Bangalore Community Leader. I bagged 2 special awards last year(2019) : Firstly, “The Tip of Captain’s Hat Award” at Dockercon 2019, San Francisco and secondly, “2019 Docker Community Award“. I was overwhelmed to receive the first award in front of around 5000 audience.

13 Comments

free teens webcams · 26th July 2016 at 11:32 pm

If some one desires expert view concerning running a blog then i propose him/her
to pay a visit this weblog, Keep up the good work.

mobile live webcam girls · 9th August 2016 at 12:13 pm

This site certainly has all of the information I needed concerning this subject and didn’t know who to ask.

CHATURBATE · 15th August 2016 at 12:53 am

Thanks for one’s marvelous posting! I definitely enjoyed reading it, you’re a great author.I will be sure to bookmark your blog and will often come back very
soon. I want to encourage one to continue your great writing, have a nice holiday
weekend!

live chat with shemales · 19th August 2016 at 3:38 am

Great post. I was checking continuously this blog and I’m impressed!
Very useful info specially the last part 🙂 I care for such info a lot.

I was looking for this certain info for a long time. Thank you and best of luck.

bdsm webcam · 20th August 2016 at 5:00 pm

Excellent way of explaining, and good article to take data on the
topic of my presentation subject, which i am going to present in institution of
higher education.

CarmineWGoel · 1st October 2016 at 7:23 pm

This is very interesting, You are a very skilled blogger.
I have joined your feed and look forward to seeking more of your magnificent post.
Also, I’ve shared your web site in my social networks!

Felton Lemmond · 10th October 2016 at 10:53 pm

Greetings! I know this is kinda off topic however , I’d figured I’d ask. Would you be interested in trading links or maybe guest authoring a blog post or vice-versa? My blog discusses a lot of the same topics as yours and I believe we could greatly benefit from each other. If you are interested feel free to shoot me an email. I look forward to hearing from you! Fantastic blog by the way!|

Obudowy Kominków · 12th October 2016 at 8:42 am

It’s a pity you don’t have a donate button! I’d certainly donate to this outstanding blog! I suppose for now i’ll settle for book-marking and adding your RSS feed to my Google account. I look forward to brand new updates and will talk about this website with my Facebook group. Chat soon!

    ajeetraina · 12th October 2016 at 3:20 pm

    Thanks a lot. There is no donation button, sorry. This is meant free sharing and contributing towards the Docker community. Thank You.

KOMINKI GDANSK · 12th October 2016 at 1:14 pm

Hi this is somewhat of off topic but I was wanting to know if blogs use WYSIWYG editors or if you have to manually code with HTML. I’m starting a blog soon but have no coding know-how so I wanted to get advice from someone with experience. Any help would be greatly appreciated!

    ajeetraina · 12th October 2016 at 3:18 pm

    You can use wordpress to keep it simple.

KelsiPBurk · 13th October 2016 at 12:07 am

I have read a lot of content on the topic of the blogger
lovers however this paragraph is actually a nice component of
writing, make it up.

Leone Chessher · 13th October 2016 at 11:54 pm

I precisely wanted to thank you so much once more. I do not know what I would’ve sorted out in the absence of the type of opinions provided by you over such field. It previously was a real terrifying situation for me, nevertheless coming across your expert technique you solved it forced me to weep for joy. Now i am thankful for your help as well as hope that you realize what a great job you happen to be accomplishing educating many others through your webpage. I am certain you’ve never come across any of us.

Leave a Reply

Your e-mail address will not be published. Required fields are marked *