0

I'm trying to doing some bandwidth test by run iperf on my device,

My Network Max Bandwith is 100 Mbps (test by speed test CLI - https://github.com/sivel/speedtest-cli)

And I ran the iperf UDP bandwidth test (like this $(iperf3 -c $server_ip -u -b 500M ))

And then I get the result (almost 500Mbps in client side message)

Is the result right ?

All the possibilities now I think is that the client side iperf is just calculate the sender bandwidth (because of UDP)

  • `iperf` normally is correct. But you could double check with a second tool like `dstat -nf` and watch the bandwidth there while `iperf` is running. – Thomas Jun 02 '17 at 15:53

2 Answers2

1

udp is a best effort protocol so iperf probably doesn't check that the packets actually arrived. Also -b sets "bandwidth to send at in bits/sec or packets per second" which you set at 500M. So I think you're just testing that your nic driver can send at 500Mbps.

I would not use udp or limit the bandwidth if you want to test a network path between nodes. ie. just iperf -c server_ip

user192749
  • 391
  • 4
  • 10
0

When using UDP, you really should check the output on the server side. UDP has no congestion control, so yes, the client just creates a constant bitrate stream. However, iperf on the server side will display the received bitrate, as well as jitter and packet loss.

What's the reason for using UDP? It's mostly useful for specialized cases, like checking jitter with various packet sizes. TCP is much more useful with iperf for cases like this (you may have to adjust the window size if you have a large delay between the client and the server).

Here's a sample output in UDP mode on the server side:

[  3] local 10.50.15.19 port 5001 connected with 10.50.200.226 port 53516
[ ID] Interval       Transfer     Bandwidth        Jitter   Lost/Total Datagrams
[  3]  0.0-10.0 sec  1.25 MBytes  1.05 Mbits/sec   1.326 ms    0/  893 (0%)
[  4] local 10.50.15.19 port 5001 connected with 10.50.200.226 port 57697
[  4]  0.0-10.0 sec  1.25 MBytes  1.05 Mbits/sec   2.775 ms    1/  892 (0.11%)
[  4]  0.0-10.0 sec  2 datagrams received out-of-order