Networking – iperf giving incorrect results

iperfnetworkingperformance

I've just had new broadband installed, and wanted to test its throughput using iperf3. However it appears to be giving considerably different results than more conventional speed tests.

E:\tmp> iperf3 -c 3.testdebit.info
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-10.01  sec  13.1 MBytes  11.0 Mbits/sec                  sender
[  4]   0.00-10.01  sec  13.1 MBytes  11.0 Mbits/sec                  receiver

Whereas online speed tests show the expected results of ~150 Mbits

3.testdebit.info has been tested from azure and is consistently around 330Mbits (though who knows what that means any more!)

I have tried various different servers, including a linux box hosted on azure – that delivers ~100Mbits to another azure box. This was also performed on port 80, to rule out any ISP throttling. All of those results are comparable.

Downloading a 3.5gb file in 210 seconds, works out to approximately 130Mbit

Can anyone shed any light on why iperf3 might be so low (or am I being really stupid and reading something wrong!)

These are all on the same computer, over ethernet so no wireless etc to get in the way.

edited to add

Performing the same test with iperf2 (on windows client (iPerf 2.0.5-3) and ubuntu (iperf version 2.0.5)) gives these results

E:\tmp\iperf2> iperf -c <hidden>.cloudapp.net -p 5201
------------------------------------------------------------
Client connecting to <hidden>.cloudapp.net, TCP port 5201
TCP window size: 63.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.2 port 51816 connected with <hidden> port 5201
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.1 sec  12.1 MBytes  10.0 Mbits/sec

The same performed from a linux based NAS

Nas:~# iperf3 -c 3.testdebit.info
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  14.5 MBytes  12.2 Mbits/sec    0             sender
[  4]   0.00-10.00  sec  14.5 MBytes  12.2 Mbits/sec                  receiver

And with the -R flag

E:\tmp> iperf3 -c 3.testdebit.info -R
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  58.0 MBytes  48.6 Mbits/sec    0             sender
[  4]   0.00-10.00  sec  57.0 MBytes  47.8 Mbits/sec                  receiver

To ensure it isn't a server issue, I have upgraded the azure VM to a size that now pulls 600Mbit up / 1Gbit down from the 3.testdebit.info server

In response to John Looker's answer

My main purpose of the question was trying to understand why iperf was giving such varied results. I understand that uploads are heavily shared, and aren't too concerned with that (or at least its a different question!)

The Azure servers I was using were in North and West Europe (Amsterdam and Ireland I believe) and with an online speedtest achieved in the area of 240Mb/s

It does however appear that multithreading was the issue, I have just rerun the test, using four threads instead of the default one –

E:\tmp>iperf3 -c 3.testdebit.info -R -P 5
Connecting to host 3.testdebit.info, port 5201
Reverse mode, remote host 3.testdebit.info is sending
- - - - - - - - - - - - - - - - - - - - - - - - -
[SUM]   0.00-10.00  sec   195 MBytes   163 Mbits/sec   50             sender
[SUM]   0.00-10.00  sec   190 MBytes   160 Mbits/sec                  receiver

Best Answer

Good conventional speed tests are multi-threaded and create multiple connections to the speed test server. Thus maxing out your connection to its full potential.

http://www.thinkbroadband.com/faq/sections/flash-speed-test.html#324

iPerf3 appears to only create two connections (using the default options), which may not be enough to max out your 152Mb broadband, particularly when congestion comes into play.
Your download test also suggests multi-threaded connections.

Downloading a 3.5gb file in 210 seconds, works out to approximately 130Mbit

Your calculation is wrong however.

((3.5GB x 8bits x1024x1024x1024 ) / 210s ) / 1000000Mbit = 143Mb/s average.

An average speed of 143Mb/s is good for a download on the 152Mb tier.

While the 152Mb tier will max out at 161Mb/s burst download speed (your modem is over-profiled to guarantee speeds), average speeds will often be slightly lower due to several factors.

Rate limiting by the server.
TCP Receive Window needs time to ramp up speed.
Cable modem request-grant cycle.
Congestion at the node. You're sharing your cable connection (and therefore your downstream channels) with hundreds of other people. The 8 x 256 QAM downstream channels you have locked on your cable modem have a maximum usable bandwidth of 400Mb in total, coming from the node. This is shared between you and all the other users on your cable with the same channels as you. When other users are using their connection during your download, the speeds will naturally vary a bit.
Congestion on the route.
Congestion at the server.
Any packet loss and re-transmission.

Upstream bandwidth is highly contended with other users on your cable to the node.

If you have 2 x 16 QAM upstream channels locked, then you're sharing 2 x 17Mb = 34Mb with many other users. If you have 2 x 64 QAM upstream channels locked, then you're sharing 2 x 27Mb = 54Mb with many other users.

Over long distances latency will become a factor in the speeds you can achieve.

You didn't state which Azure server you were using, whether UK, Europe or America.

Your iPerf3 server is in France and may or may not route through LINX, depending on your location. Congestion on the route could be a problem sometimes, once it leaves the VM network, particularly at peering points.

Non-standard ports will often be treated as P2P traffic. http://www.thinkbroadband.com/faq/sections/flash-speed-test.html#323

Although there is no downstream traffic management on downloads, streaming, gaming and so on, on the 30Mb and above tiers, if your traffic is classed as P2P then it will be traffic managed and the speed reduced during peak hours.

The reason is that the upstream bandwidth is very scarce as it's shared by hundreds of users, and so any program that might swamp the upstream would be very bad for everybody on your cable. That's also why the upstream is still traffic managed.

Outside peak-time you should be able to max out your connection in any way you like.

Beware tests that use small file sizes. There are a range of test files you can use here: http://www.thinkbroadband.com/download/
Your download was unlikely to be delivered by a CDN or cached inside the VM network. When I was on 152Mb I regularly downloaded and streamed at 161Mb directly from servers. CDN's tend to make delivery slower rather than faster!

You need to provide further specifics on your testing strategy in order to answer the original question.

Related Solutions

Networking – Why is the UDP so slow

In this case, the problem is that iperf's default speed for UDP is very slow (see the other answers). But for less extreme speed differences, check this question on serverfault.com.

Following a quote from pehrs's answer

Each frame goes through several buffers as you send it: The application buffer, The Protocol Buffer, The Software interface buffer and the Hardware interface buffer. As you start stressing the stack by sending high speed data you will fill up these buffers and either block or lose data. You also have strategies for timeliness and polling that can impact your performance. For example, by using a larger buffer and poll less often you can get much better performance while sacrificing latency.

TCP is optimized for high speed bulk transfers while UDP is optimized for low latency in the Linux kernel. This has an impact on buffer sizes and how data is polled and handed over. In addition to this, you frequently have offloading to hardware for TCP. I would expect considerably better performance for TCP compared to UDP.

Note that sending high speed data over UDP is usually a bad idea, unless you implement your own congestion control. TCP protects your network from congestion collapses. Use UDP when you have small amounts of data or high timeliness requirements.

Network Loopback Test – How to Perform Using TTCP or IPERF

I reviewed the help for IPERF and I think I got it now.

On server side:

C:\>iperf -s -B 10.1.1.1
------------------------------------------------------------
Server listening on TCP port 5001
Binding to local address 10.1.1.1
TCP window size: 8.00 KByte (default)
------------------------------------------------------------
[160] local 10.1.1.1 port 5001 connected with 10.1.1.2 port 35202
[ ID] Interval       Transfer     Bandwidth
[160]  0.0-10.0 sec   420 MBytes   352 Mbits/sec

On client side:

C:\>iperf -c 10.1.1.1 -B 10.1.1.2
------------------------------------------------------------
Client connecting to 10.1.1.1, TCP port 5001
Binding to local address 10.1.1.2
TCP window size: 8.00 KByte (default)
------------------------------------------------------------
[132] local 10.1.1.2 port 35202 connected with 10.1.1.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[132]  0.0-10.0 sec   420 MBytes   352 Mbits/sec

C:\>

Let me know if you see any errors here.

I would still like to know if this is possible, and how to do it using TTCP? If you know the answer to this, please post it.

Best Answer

Related Solutions

Networking – Why is the UDP so slow

Network Loopback Test – How to Perform Using TTCP or IPERF

Related Question