Iperf results on Bandwidth and Transfer do not make sense

Question

I'm having trouble understanding why iperf is behaving the way it is. I'm just trying to send UDP traffic from a Raspberry Pi to my Computer.

This is what it looks like on the Client Side:

pi@raspberrypi:~ $ iperf -c 192.168.0.5 -t 10 -i 1 -u -b 10000m
------------------------------------------------------------
Client connecting to 192.168.0.5, UDP port 5001
Sending 1470 byte datagrams, IPG target: 1.18 us (kalman adjust)
UDP buffer size:  160 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.200 port 51303 connected with 192.168.0.5 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 1.0 sec  11.5 MBytes  96.3 Mbits/sec
[  3]  1.0- 2.0 sec  11.4 MBytes  95.3 Mbits/sec
[  3]  2.0- 3.0 sec  11.4 MBytes  95.8 Mbits/sec
[  3]  3.0- 4.0 sec  11.3 MBytes  95.2 Mbits/sec
[  3]  4.0- 5.0 sec  11.4 MBytes  95.5 Mbits/sec
[  3]  5.0- 6.0 sec  11.4 MBytes  95.5 Mbits/sec
[  3]  6.0- 7.0 sec  11.4 MBytes  95.4 Mbits/sec
[  3]  7.0- 8.0 sec  11.3 MBytes  95.0 Mbits/sec
[  3]  8.0- 9.0 sec  11.3 MBytes  94.8 Mbits/sec
[  3]  9.0-10.0 sec  11.4 MBytes  95.5 Mbits/sec
[  3]  0.0-10.0 sec   114 MBytes  95.4 Mbits/sec
[  3] Sent 2 datagrams
[  3] Server Report:
[  3]  0.0-10.0 sec   114 MBytes  95.4 Mbits/sec   0.201 ms    0/81153 (0%)

---

Now this is what it looks like on the Server Side:

Comp-Name:Directory username$ iperf -s -i 1 -u
------------------------------------------------------------
Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size:  768 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.5 port 5001 connected with 192.168.0.200 port 51303
[ ID] Interval       Transfer     Bandwidth        Jitter   Lost/Total Datagrams
[  3]  0.0- 1.0 sec  11.4 MBytes  95.6 Mbits/sec   0.136 ms    0/ 8128 (0%)
[  3]  1.0- 2.0 sec  11.4 MBytes  95.4 Mbits/sec   0.120 ms    0/ 8113 (0%)
[  3]  2.0- 3.0 sec  11.4 MBytes  95.5 Mbits/sec   0.149 ms    0/ 8124 (0%)
[  3]  3.0- 4.0 sec  11.4 MBytes  95.5 Mbits/sec   0.270 ms    0/ 8122 (0%)
[  3]  4.0- 5.0 sec  11.4 MBytes  95.5 Mbits/sec   0.255 ms    0/ 8119 (0%)
[  3]  5.0- 6.0 sec  11.4 MBytes  95.5 Mbits/sec   0.272 ms    0/ 8124 (0%)
[  3]  6.0- 7.0 sec  11.4 MBytes  95.4 Mbits/sec   0.390 ms    0/ 8109 (0%)
[  3]  7.0- 8.0 sec  11.3 MBytes  95.0 Mbits/sec   0.202 ms    0/ 8079 (0%)
[  3]  8.0- 9.0 sec  11.3 MBytes  94.9 Mbits/sec   0.273 ms    0/ 8070 (0%)
[  3]  9.0-10.0 sec  11.4 MBytes  95.4 Mbits/sec   0.273 ms    0/ 8113 (0%)
[  3]  0.0-10.0 sec   114 MBytes  95.4 Mbits/sec   0.202 ms    0/81153 (0%)

If I am trying to push 10,000 Mbps of data, why are the Bandwidth (Mbits/sec) and Transfer (MBytes) capping themselves at ~95 and ~11.4?

Shouldn't iperf try to push the traffic and show loss after capping instead? Am I missing something obvious here?

Thanks, moodieftw

Answer 1

The Raspberry Pi 1,2 and zero have a 100Mb/s network interface card, so this is likely what caps the traffic.
(the raspberry pi 3 has a gigabit Ethernet interface but it is connected to the processor through USB 2, so is limited to USB 2 speed at 300Mb/s).

The reported Transfer and bandwidth are consistent with a 100Mb/s connection. As hinted by @Ron Maupin in comment, there are overhead (headers and processing) that cause the usable bandwidth to be slightly less than the interface speed.

Shouldn't iperf try to push the traffic and show loss after capping instead?

No, this is not how it works. The reported bandwidth is what is actually sent.

Answer 2

The client socket writes are blocking or getting EAGAIN or ENOBUFS because the window is small. Increase it with -w and then the kernel will drop after the write but before the transmit. Also, the output per -e might be helpful. This won't impact the end/end measurement per the 100Mb/s link but may cause the client to exceed that. This is due to UDP being connectionless and such that the traffic will be dropped by the client's kernel.