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 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
  • Could you do me a favor and retest with iperf 2.0.x instead of iperf3? iperf3 was a big rewrite that I don't trust, and I wonder if this is further evidence. – Spiff Aug 13 '15 at 17:36
  • @Spiff question edited with further results - connecting to public servers gave peculiar results! (values given in bits - it seemed - but they didn't add up) – Michael B Aug 13 '15 at 17:51
  • The values add up, it's just that file sizes are usually given in MebiBytes (MiB), whereas network speeds are usually given in megabits (Mb). So you can't just multiply/divide by 8. It's closer to 8.2 for kb/KiB, 8.4 for Mb/MiB, and 8.6 for Gb/GiB. – Spiff Aug 13 '15 at 18:17
  • I don't understand how it can get from 48.6Mbits to ~130Mbits by multiplying by anything close to eight though! - oddly though, 12Mbits is about upload speed – Michael B Aug 13 '15 at 18:29
  • Just so I can be sure I'm following you correctly, when you say, "Downloading a 3.5gb file in 210 seconds, works out to approximately 130Mbit", does that "gb" mean gigabits (1,000,000,000's of individual bits) or does it mean GibiBytes (1,073,741,824's of 8-bit Bytes)? – Spiff Aug 13 '15 at 20:33
  1. 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.


  1. 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.

  2. 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.

  1. 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.

  1. 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.

  1. Beware tests that use small file sizes. There are a range of test files you can use here: http://www.thinkbroadband.com/download/

  2. 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.

  • It appears that it was a multithreading issue, after setting iperf to multithread it gave consistent results - see amended question (and thank you!) – Michael B Aug 21 '15 at 8:33
  • You're welcome. It would be useful for you to run a comparison with thinkbroadband.com/speedtest.html and post the graph result. You may find that shows congestion at certain times of the day on the green HTTP x 1 test, whereas the HTTP x 6 test maxes out. – John Looker Aug 21 '15 at 13:54
  • After the initial confusion of forgetting I was logged into Azure! (how am I getting 200mb upload!) they are also giving results consistent with the other's I've seen Results here - My initial idea for wanting iperf consistent was that I was thinking of running a scripted test to check the performance by the hour - which I can now do! – Michael B Aug 21 '15 at 14:14
  • Register for Samknows. Does the same thing but from a Whitebox router and provides the analysis tools. samknows.com – John Looker Aug 21 '15 at 18:13

Beware that IPerf defaults to an "upload" test: The IPerf client (-c) sends TCP data to the IPerf server (-s). It looks like you were running the client on your LAN and connecting to an IPerf server hosted on the public Internet, so you were testing your new broadband connection's upload, not download, speed.

To test its download speed, either reverse which end you invoke as -s/-c, or use -r to specify that you want it to do a "reverse" (download) test after it does the normal test.

Beware that if your LAN machine is behind a NAT or firewall, you may have to open/map/forward a port appropriately for the download test to work.

  • Good point! I'd forgotten about that - it does improve matters, though not substantially. to ~45Mbit – Michael B Aug 13 '15 at 18:15
  • @Michael Please update your Question with these latest results. I like when you paste in IPerf output so I can see the Mb vs. MiB for myself. – Spiff Aug 13 '15 at 18:22

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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