0

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

  • You seem to be ignoring the processing time and protocol overhead. This looks pretty normal for a 100 Mbps connection. – Ron Maupin Feb 18 at 17:44
  • Which model is you raspberry pi? – JFL Feb 18 at 18:07
  • 2
    Because you told the test to run for 10s and the interface is physically 100Mbps. No amount of commandline switches will turn a 100M interface into a 10G interface. – Ricky Beam Feb 18 at 19:59
4

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.

| improve this answer | |
0

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.

| improve this answer | |
  • Forgot to say that yes the iperf client with UDP should exceed the link phy rate and lose packets. What version are you using? Iperf -v will give that – rjmcmahon Feb 27 at 2:00

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.