1

I have the following result from a UDP throughput test as measured by iperf3

$ iperf3 -u -t 10 -c 192.168.1.2 -b 100M -V
iperf 3.6+
Linux pi-raspberry1 4.4.38-v7+ #938 SMP Thu Dec 15 15:22:21 GMT 2016 armv7l
Control connection MSS 1448
Setting UDP block size to 1448
Time: Thu, 04 Oct 2018 09:58:29 GMT
Connecting to host 192.168.1.2, port 5201
      Cookie: h3wj4by4mtyobgtq42gsf62s3nfhymg6djry
[  5] local 192.168.1.1 port 40988 connected to 192.168.1.2 port 5201
Starting Test: protocol: UDP, 1 streams, 1448 byte blocks, omitting 0 seconds, 10 second test, tos 0
[ ID] Interval           Transfer     Bitrate         Total Datagrams
[  5]   0.00-1.00   sec  3.34 MBytes  28.0 Mbits/sec  2421
[  5]   1.00-2.00   sec  3.13 MBytes  26.2 Mbits/sec  2264
[  5]   2.00-3.00   sec  2.15 MBytes  18.1 Mbits/sec  1560
[  5]   3.00-4.00   sec   905 KBytes  7.41 Mbits/sec  640
[  5]   4.00-5.00   sec   486 KBytes  3.98 Mbits/sec  344
[  5]   5.00-6.00   sec  2.19 MBytes  18.4 Mbits/sec  1587
[  5]   6.00-7.00   sec  2.55 MBytes  21.4 Mbits/sec  1848
[  5]   7.00-8.00   sec  2.18 MBytes  18.3 Mbits/sec  1576
[  5]   8.00-9.00   sec  2.72 MBytes  22.8 Mbits/sec  1968
[  5]   9.00-10.00  sec  3.21 MBytes  26.9 Mbits/sec  2321
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-10.00  sec  22.8 MBytes  19.1 Mbits/sec  0.000 ms  0/16529 (0%)  sender
[  5]   0.00-10.77  sec  22.8 MBytes  17.8 Mbits/sec  22.003 ms  4/16529 (0.024%)  receiver
CPU Utilization: local/sender 9.8% (1.5%u/8.2%s), remote/receiver 1.5% (0.0%u/1.5%s)

If UDP constantly sends data without caring if they arrived or not, why is it that the amount of MBytes sent differs each second as well as the amount of total Datagrams sent does? Moreover I see that the same number of MBytes is seen by both the server and the client at the Summary Results, but the Bitrate is not the same, does this have to do with the bigger interval taken into account by the server (10.77 seconds instead of 10)?

Improve this question
1
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can provide and accept your own answer.
    – Ron Maupin ♦
    Dec 25, 2018 at 9:58

2 Answers 2

Reset to default
1

Here's a iperf3 client RaspberryPi3B running current Raspbian to a iperf3 server MacbookPro8,2 running current Fedora 29 x86_64, across a cheap DLink DGS-1005A gigabit ethernet switch, same parameters as the pi-raspberry1 test in the question:

$ iperf3 -u -t 10 -c 192.168.255.43 -b 100M -V
iperf 3.1.3
Linux vk5tu 4.14.79-v7+ #1159 SMP Sun Nov 4 17:50:20 GMT 2018 armv7l
Time: Sun, 18 Nov 2018 12:57:31 GMT
Connecting to host 192.168.255.43, port 5201
      Cookie: vk5tu.1542545851.946174.2f2a05466
[  4] local 192.168.255.21 port 43811 connected to 192.168.255.43 port 5201
Starting Test: protocol: UDP, 1 streams, 8192 byte blocks, omitting 0 seconds, 10 second test
[ ID] Interval           Transfer     Bandwidth       Total Datagrams
[  4]   0.00-1.00   sec  10.4 MBytes  86.8 Mbits/sec  1325  
[  4]   1.00-2.00   sec  11.4 MBytes  95.8 Mbits/sec  1462  
[  4]   2.00-3.00   sec  11.4 MBytes  95.8 Mbits/sec  1462  
[  4]   3.00-4.00   sec  11.4 MBytes  95.8 Mbits/sec  1462  
[  4]   4.00-5.00   sec  11.4 MBytes  95.9 Mbits/sec  1463  
[  4]   5.00-6.00   sec  11.4 MBytes  95.8 Mbits/sec  1462  
[  4]   6.00-7.00   sec  11.4 MBytes  95.9 Mbits/sec  1463  
[  4]   7.00-8.00   sec  11.4 MBytes  95.8 Mbits/sec  1462  
[  4]   8.00-9.00   sec  11.4 MBytes  95.9 Mbits/sec  1463  
[  4]   9.00-10.00  sec  11.4 MBytes  95.8 Mbits/sec  1462  
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-10.00  sec   113 MBytes  94.9 Mbits/sec  0.024 ms  0/14486 (0%)  
[  4] Sent 14486 datagrams
CPU Utilization: local/sender 19.3% (0.5%u/18.8%s), remote/receiver 0.1% (0.0%u/0.1%s)

What's the provenance of the pi-raspberry1's software? Compare with the stock current Raspbian: pi-raspberry1's kernel is much older; pi-raspberry1's iperf3 version is newer. If you compiled the newer iperf3 did you do it via the Debian packaging system to make sure you compiled with the same compiler options and patches?

Note the difference in CPU: pi-raspberry1: 9.8% (1.5%u/8.2%s); vk5tu 19.3% (0.5%u/18.8%s). Did you check CPU usage during the test to ensure that the transmission was not CPU-bound? Also the USB bus on the RPi is shared between the ethernet, WLAN and USB ports, so that USB bus needs to have no other traffic whilst running the iperf tests. That pi-raspberry1 used three times as much system CPU than vk5tu whilst doing only 20% of the throughput suggests that either pi-raspberry1 is not recent RPi hardware or that there have been substantial improvements in the kernel from 4.4.38 (Dec 2016) to 4.14.79 (Nov 2018).

Have you repeated the test with a stock current system?

As you can see from the above, it is important to give a lot of information about the test environment when asking about performance issues. Best wishes.

Edit:

For your assistance, here's the same test with no output pacing, to stress the RPi3B:

$ iperf3 -u -t 10 -c 192.168.255.43 -b0 -V
iperf 3.1.3
Linux vk5tu 4.14.79-v7+ #1159 SMP Sun Nov 4 17:50:20 GMT 2018 armv7l
Time: Sun, 18 Nov 2018 13:16:45 GMT
Connecting to host 192.168.255.43, port 5201
      Cookie: vk5tu.1542547005.185182.16ba7c754
[  4] local 192.168.255.21 port 39955 connected to 192.168.255.43 port 5201
Starting Test: protocol: UDP, 1 streams, 8192 byte blocks, omitting 0 seconds, 10 second test
[ ID] Interval           Transfer     Bandwidth       Total Datagrams
[  4]   0.00-1.01   sec  11.6 MBytes  96.4 Mbits/sec  1480  
[  4]   1.01-2.01   sec  11.4 MBytes  95.8 Mbits/sec  1460  
[  4]   2.01-3.00   sec  11.4 MBytes  95.8 Mbits/sec  1460  
[  4]   3.00-4.00   sec  11.4 MBytes  95.8 Mbits/sec  1460  
[  4]   4.00-5.00   sec  11.4 MBytes  95.8 Mbits/sec  1460  
[  4]   5.00-6.01   sec  11.5 MBytes  95.8 Mbits/sec  1470  
[  4]   6.01-7.00   sec  11.4 MBytes  95.8 Mbits/sec  1460  
[  4]   7.00-8.00   sec  11.4 MBytes  95.8 Mbits/sec  1460  
[  4]   8.00-9.00   sec  11.4 MBytes  95.8 Mbits/sec  1460  
[  4]   9.00-10.01  sec  11.5 MBytes  95.9 Mbits/sec  1470  
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-10.01  sec   114 MBytes  95.9 Mbits/sec  0.940 ms  0/11552 (0%)  
[  4] Sent 11552 datagrams
CPU Utilization: local/sender 18.5% (1.1%u/17.4%s), remote/receiver 1.7% (0.2%u/1.4%s)
Improve this answer
0

As @vk5tu answered, the low bit rate and the difference of sent datagrams in each interval are probably due to the limitations of the device itself. It was as many datagrams the device could generate and put on the network at this particular point in time. Theses limitations can be at the CPU, bus or NIC (buffers) level. That's why, depending on the load that you have running on your device, you'll see different results.

About the sender/receiver bitrate difference, it is indeed due to the interval being different. It took 10.77 seconds for the receiver to see all incoming packets:

  • Sender
    • 16529 datagrams of 1448 bytes: 23933992 bytes or about 191.47 Mbits
    • 191.47 Mbits received in 10 seconds: 19.147 Mbits/s
  • Receiver (4 datagrams lost)
    • 16525 datagrams of 1448 bytes: 23928200 bytes or about 191.43 Mbits
    • 191.43 Mbits received in 10.77 seconds: 17.774 Mbits/s
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.