Network stress-testing with Iperf

posted in: Software | 3

logo_iperf_commandSo recently I took a look at how you would go about troubleshooting network issues and monitoring network performance using Iperf on RISC OS as a server or a client.

Another use case for Iperf would be stress-testing the stability of a system when it comes under heavy bandwidth utilisation. This will be very handy when trying to gauge what kind of limits a public-facing server you run has – web server, game server etc.

In this example, I took a look at how much load my Linux server running under local IP address could take. The system is used as a Media Server, which sometimes is in use by about four or five seperate devices at the time-time, with some devices connecting via WAN and some on the LAN.

So given the use case, I would say it would be quite crucial to identify any issues with stability – there’s nothing worse than having the other half chew my ear off because the media server she’s streaming from decided to crash suddenly.

If you’re looking to try this out for yourself, keep in mind that you can use Iperf on RISC OS as the client or the server in these tests – and the tests can run between systems sitting on the LAN or remotely via a WAN IP address.

All you need is Iperf running on both systems, with one specified as a server and the other a client. There’s no graphical interface for Iperf, so if you’ll need to enter the below commands using the RISC OS command-line, which can be accessed by pressing F12.


This stress-test will be performed using the simultaneous upload and download option in Iperf. This will reveal weak spots and give you an idea of how upload and download together will affect your speeds.

Server-side commands

To begin, run the below command on the system you’ll be using as the Iperf server. -s enables the server side, while -w specifies the TCP Window size. The default is usually 64KB which is too small for a bandwidth test I find. 1MB is a good size to use.

iperf -s -w 1MB

Once run, the below should be displayed on the server:

Server listening on TCP port 5001
TCP window size: 1.00 MByte

Client-side commands

So now we need to initiating the test on the client and specify the type of tests we’d like to run. So on the client, I used the below command. Just like in previous examples, -c specifies the IP address of the Iperf server and -w specifies the TCP Windows size. As we’re wanting to test upload & download traffic simultaneously, -d is the option to use. This tells Iperf to run upload and download tests at the same time.

iperf -c -w 1MB -d -t 20 -P 10

This command will then send TCP traffic to the server – which will display a number of results at 1 second intervals.

Viewing results on the server

Client connecting to, TCP port 5001
TCP window size: 1.00 MByte
[ 7] local port 62401 connected with port 5001
[ 6] local port 62400 connected with port 5001
[ 4] local port 62398 connected with port 5001
[ 5] local port 62399 connected with port 5001
[ 8] local port 5001 connected with port 42162
[ 9] local port 5001 connected with port 42163
[ 10] local port 5001 connected with port 42165
[ 11] local port 5001 connected with port 42164
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-20.0 sec 52.23 MBytes 22 Mbits/sec
[ 5] 0.0-20.0 sec 52.19 MBytes 22 Mbits/sec
[ 7] 0.0-20.0 sec 55.76 MBytes 23 Mbits/sec
[ 6] 0.0-20.0 sec 57.12 MBytes 24 Mbits/sec
[SUM] 0.0-20.0 sec 214 MBytes 91 Mbits/sec
[ 9] 0.0-20.0 sec 52.42 MBytes 22 Mbits/sec
[ 10] 0.0-20.0 sec 49.71 MBytes 20 Mbits/sec
[ 8] 0.0-20.0 sec 50.01 MBytes 21 Mbits/sec
[ 11] 0.0-20.0 sec 52.91 MBytes 22 Mbits/sec
[SUM] 0.0-20.0 sec 200 MBytes 86 Mbits/sec

The above results show multiple download and upload connections opened to the server – and the overall size of the packets sent over. The result also displays performance metrics for the tests run at the intervals specified. As you can see with these results, the server handled the traffic well and didn’t experience any kind of latency issues, with traffic sticking to the same speed across tests. If you were to have issues with the system you’re testing, you’d either see high latency with some of the tests or you’d experience a loss of connection if the system cannot deal with the load.

You can continue to rack up the size of the TCP Window to increase the size of the tests, so you can then find at what point your system will no longer be able to cope.

If you are trying to properly stress-test a system that will be regularly coming under very heavy traffic, then you might want to setup multiple Iperf clients running on different Internet connections to all feed into the server.

If you want to find out more about using Iperf on RISC OS or indeed on any system that it is available for, check out my previous article here, which also covers running bandwidth tests.

3 Responses

    • Sion

      Yes they should do. The RISC OS port of Iperf seems to be exactly the same as the *nix version.

  1. DraupnirSammler

    This two WP links shows why the programs can “interoperate” on two different systems. The only thing to keep in mind is: there are at least two versions of Iperf – and Iperf3, wich is a complete reimplementation and not backwards compatible.

    Iperf needs to be installed in Linux before it can be used as it’s not a ‘standard’ tool.

Leave a Reply to Sion Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.