Iperf: Iperf3 Always Sends Bandwidth 10.5Mbits/sec or Greater with TCP

Created on 1 Jul 2016 · 4Comments · Source: esnet/iperf

Running "iperf3 -s" on one machine and "iperf3 -c (server ip) -b 10k" on the other, I receive the following output on the client machine:

Connecting to host (server ip), port 5201
[ 4] local (client ip) port 59638 connected to (server ip) port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 1.16 MBytes 9.75 Mbits/sec 0 61.5 KBytes
[ 4] 1.00-2.00 sec 1.25 MBytes 10.5 Mbits/sec 0 126 KBytes
[ 4] 2.00-3.00 sec 1.25 MBytes 10.5 Mbits/sec 0 132 KBytes
[ 4] 3.00-4.00 sec 1.25 MBytes 10.5 Mbits/sec 1 97.5 KBytes
[ 4] 4.00-5.00 sec 1.25 MBytes 10.5 Mbits/sec 0 106 KBytes
[ 4] 5.00-6.00 sec 1.25 MBytes 10.5 Mbits/sec 0 115 KBytes
[ 4] 6.00-7.00 sec 1.25 MBytes 10.5 Mbits/sec 0 122 KBytes
[ 4] 7.00-8.00 sec 1.25 MBytes 10.5 Mbits/sec 0 128 KBytes
[ 4] 8.00-9.00 sec 1.25 MBytes 10.5 Mbits/sec 1 94.9 KBytes
[ 4] 9.00-10.00 sec 1.25 MBytes 10.5 Mbits/sec 0 104 KBytes

[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 12.4 MBytes 10.4 Mbits/sec 2 sender
[ 4] 0.00-10.00 sec 12.3 MBytes 10.3 Mbits/sec receiver

Any request for a TCP connection with bandwidth below 10.5 Mbits/s is ignored without error and I cannot find any documentation of this limitation. UDP, on the other hand, is able to achieve smaller bandwidths, with a lower limit of 655 Kbits/s.

bug wontfix

Source

travis1230

Most helpful comment

This is because of the default TCP length (-l flag), add for ex. "-l512" and it will work

SecDWizar on 5 Jul 2016

❤2

All 4 comments

This is because of the default TCP length (-l flag), add for ex. "-l512" and it will work

SecDWizar on 5 Jul 2016

❤2

That's a reasonable workaround. I think part of the problem is also that the throttling code only keeps track of time in units of whole seconds, which limits the granularity to which we can limit the sending rate. Using the newer per-socket-based pacing on recent iperf3 and recent Linux might also be a good solution.

bmah888 on 12 Aug 2016

That's a funny bug I'm also encountering. Within reverse test (-R), it seems not occur.

mths0x5f on 22 Nov 2016

Closing because there's a workaround / fix for it. Recommend using -l 100 or something similar for this use case. We have some text in the recently-added FAQ on this subject.

bmah888 on 14 Apr 2017

❤1

Was this page helpful?

0 / 5 - 0 ratings