UDP iperf3 with no result, but iperf2 have results

[ghost999991]

Context

I'm troubleshooting the UDP iperf throughput , it can show results for iperf2, but nothing for iperf3. (TCP works fine for both)
I'm wondering what feature in UDP iperf3 or which command I missed that cause the problem.

• Version of iperf:
  iperf 2.0.9
  iperf 3.1.3

• Scenario
  Pc -> set as server
  Device -> set as client

Bug Report

iperf3
client # iperf3 -c 192.168.2.2 -i1 -p5002 -u -b1100M
Unable to connecto to server: Connection refused

Server listening on 5002
No result

If I switch the role, let the server side become client, the client side become server, then add -R (since I'm debugging the DL)

Now pc set as client side and reverse mode
C:\iperf-3.1.3-win64>iperf3 -c 192.168.2.1 -i1 -p5002 -b1100M -R -u
Connecting to host 192.168.2.1, port 5002
Reverse mode, remote host 192.168.2.1 is sending
[ 4] local 192.168.1.2 port 53120 connected to 192.168.2.1 port 5002
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-1.00 sec 0.00 Bytes 0.00 bits/sec 0.000 ms 0/0 (0%)
[ 4] 1.00-2.01 sec 0.00 Bytes 0.00 bits/sec 0.000 ms 0/0 (0%)
[ 4] 2.01-3.01 sec 0.00 Bytes 0.00 bits/sec 0.000 ms 0/0 (0%)
[ 4] 3.01-4.00 sec 0.00 Bytes 0.00 bits/sec 0.000 ms 0/0 (0%)
[ 4] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec 0.000 ms 0/0 (0%)
[ 4] 5.00-6.01 sec 0.00 Bytes 0.00 bits/sec 0.000 ms 0/0 (0%)
[ 4] 6.01-7.01 sec 0.00 Bytes 0.00 bits/sec 0.000 ms 0/0 (0%)
[ 4] 7.01-8.00 sec 0.00 Bytes 0.00 bits/sec 0.000 ms 0/0 (0%)
[ 4] 8.00-9.01 sec 0.00 Bytes 0.00 bits/sec 0.000 ms 0/0 (0%)
[ 4] 9.01-10.01 sec 0.00 Bytes 0.00 bits/sec 0.000 ms 0/0 (0%)
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-10.01 sec 1.29 GBytes 1.10 Gbits/sec 0.000 ms 0/0 (0%)
[ 4] Sent 0 datagrams

---

iperf2
-> don't have to switch the role, pc as server, and device as client

client # iperf -c 192.168.2.2 -i1 -p5002 -u -b1100M
C:\iperf-2.0.9-win64>iperf -s -i1 -p5002 -u
Server listening on UDP port 5002
Receiving 1470 byte datagrams
UDP buffer size: 208 KByte (default)
[ 3] local 10.20.194.237 port 5002 connected with 192.168.2.1 port 64116
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 3] 0.0- 1.0 sec 62.6 MBytes 525 Mbits/sec 0.018 ms 6483/51141 (13%)
[ 3] 1.0- 2.0 sec 63.7 MBytes 535 Mbits/sec 0.017 ms 64823/110284 (59%)
[ 3] 2.0- 3.0 sec 63.6 MBytes 534 Mbits/sec 0.020 ms 52146/97547 (53%)
[ 3] 3.0- 4.0 sec 63.7 MBytes 534 Mbits/sec 0.026 ms 45757/91199 (50%)
[ 3] 4.0- 5.0 sec 63.7 MBytes 534 Mbits/sec 0.016 ms 52506/97949 (54%)
[ 3] 5.0- 6.0 sec 63.7 MBytes 534 Mbits/sec 0.017 ms 48647/94090 (52%)
[ 3] 6.0- 7.0 sec 14.0 MBytes 118 Mbits/sec 121.010 ms 10789/20789 (52%)
[ 3] 7.0- 8.0 sec 0.00 Bytes 0.00 bits/sec 0.000 ms 0/ 0 (0%)
[ 3] 8.0- 9.0 sec 53.9 MBytes 452 Mbits/sec 0.018 ms 221549/260026 (85%)
[ 3] 9.0-10.0 sec 63.9 MBytes 536 Mbits/sec 0.017 ms 44849/90431 (50%)
[ 3] 0.0-10.3 sec 532 MBytes 433 Mbits/sec 0.015 ms 555673/935371 (59%)

• Expected Behavior
  Iperf3 should get something like iper2

• Actual Behavior
  Iperf3 cannot catch anything

• Possible Solution
  Thinking......

If anyone know the reason, please let me know. Thanks!

[bmah888]

What relation does this problem have to the behavior you described in #1217?

I see where you are somehow using iperf-3.1.3, which is extremely old. There are some fixes starting around iperf-3.1.5 (which is itself over four years old), that improve UDP behavior (in particular, the default UDP send size is something more rational than 8K, something that will fit in an MTU-sized IP packet). Note that the current version of iperf3 is 3.10.1.

[ghost999991]

What relation does this problem have to the behavior you described in #1217?

I see where you are somehow using iperf-3.1.3, which is extremely old. There are some fixes starting around iperf-3.1.5 (which is itself over four years old), that improve UDP behavior (in particular, the default UDP send size is something more rational than 8K, something that will fit in an MTU-sized IP packet). Note that the current version of iperf3 is 3.10.1.

It's another testing device for #1217 and got different results. The solutions may also different since I have tried datagram -l in this one #1219, but it seems not work.

The following is the 3.10.1 testing:

1. Server listening on 5002 (test #1)
still with no result
or
2.
C:\iperf3.10.1_64bit>iperf3 -c 192.168.2.1 -i1 -p5002 -u -b1100M -R
Connecting to host 192.168.2.1, port 5002
Reverse mode, remote host 192.168.2.1 is sending
[ 5] local 192.168.1.2 port 54092 connected to 192.168.2.1 port 5002
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-1.00 sec 27.8 MBytes 233 Mbits/sec 0.094 ms 17425/37402 (47%)
[ 5] 1.00-2.00 sec 28.2 MBytes 237 Mbits/sec 0.024 ms 17769/38006 (47%)
[ 5] 2.00-3.00 sec 28.7 MBytes 240 Mbits/sec 0.031 ms 18006/38585 (47%)
[ 5] 3.00-4.00 sec 28.2 MBytes 237 Mbits/sec 0.025 ms 18691/38957 (48%)
[ 5] 4.00-5.00 sec 29.4 MBytes 246 Mbits/sec 0.107 ms 17759/38881 (46%)
[ 5] 5.00-6.00 sec 28.9 MBytes 243 Mbits/sec 0.042 ms 17875/38651 (46%)
[ 5] 6.00-7.00 sec 28.3 MBytes 237 Mbits/sec 0.021 ms 18214/38511 (47%)
[ 5] 7.00-8.00 sec 28.4 MBytes 238 Mbits/sec 0.028 ms 18369/38743 (47%)
[ 5] 8.00-9.00 sec 28.5 MBytes 239 Mbits/sec 0.025 ms 18089/38528 (47%)
[ 5] 9.00-10.00 sec 27.2 MBytes 228 Mbits/sec 0.222 ms 18869/38415 (49%)
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.03 sec 538 MBytes 450 Mbits/sec 0.000 ms 0/386599 (0%) sender
[ 5] 0.00-10.00 sec 284 MBytes 238 Mbits/sec 0.222 ms 181066/384679 (47%) receiver

---

Summary

iperf2 -> result ~500M
iperf3.1.3 -> no result even in reverse mode
iperf3.10.1 -> result ~240M in reverse mode

---

I want to figure out why different versions got different throughput, which variables or command may be the issue?

Thanks for the reply!

[bmah888]

I see this is on Windows (at least one side is anyway)...this is a platform that we (ESnet) don't officially support. That being said, I'd expect UDP tests to work in both directions.

The only thing I can think of, off-hand, is a host-based firewall one side or the other that's disrupting some part of the communications. Is it possible that the PC might have some firewall settings that need to be disabled in order for your device to communicate with it? Note that even though you are doing a UDP test, you still need to allow TCP communication (on port 5002 in your case) for the iperf3 control connection.