Troubleshooting network problems such as throughput, packet loss and jitter issues can be tricky at the best of times, a good tool to use on RISC OS should you need to see what’s going on with your network is Iperf.
Iperf is a modern alternative for measuring TCP and UDP bandwidth performance, allowing for the tuning of various parameters and characteristics.
Quite popular on Linux systems, a RISC OS port of the command line utility is available from riscos.info. Once downloaded and run, Iperf can be accessed via the RISC OS command line. Iperf can act as a server or a client. You can use Iperf on your RISC OS computer to test traffic to another RISC OS computer running Iperf, or another non-RISC OS system, just as long as that system is also running Iperf.
Some of its features and uses include:
- Measure bandwidth, packet loss, delay jitter
- Report MSS/MTU size and observed read sizes.
- Support for TCP window size via socket buffers.
- Multi-threaded. Client and server can have multiple simultaneous connections.
- Client can create UDP streams of specified bandwidth.
- Multicast and IPv6 capable.
- Options can be specified with K (kilo-) and M (mega-) suffices.
- Can run for specified time, rather than a set amount of data to transfer.
- Picks the best units for the size of data being reported.
- Server handles multiple connections.
- Print periodic, intermediate bandwidth, jitter, and loss reports at specified intervals.
- Server can be run as a daemon.
- Use representative streams to test out how link layer compression affects your achievable bandwidth.
The primary goal of Iperf is to help in tuning TCP connections over a particular path. The most fundamental tuning issue for TCP is the TCP window size, which controls how much data can be in the network at any one point. If it is too small, the sender will be idle at times and get poor performance. The theoretical value to use for the TCP window size is the bandwidth delay product,
The basics of using iperf are quite simple. You install it on a server and a client, then run iperf -s on the server and iperf -c <IP address of server> on the client. The -s option signifies server, whilst the -c option indicates client. You need to specify the IP address of the server to connect to with the -c option.
The -i option defines the interval in seconds that iperf reports the metrics. The default time the client will run is 10 seconds, but this can be specified using the -t option (to use UDP instead, use -u). By default, the iperf server listens on port 5001, but this can be changed if required also.
The ‘iperf -h’ command will display a list of possible commands.
Unless specifically stated in the listening command on the server, Iperf will use TCP as the protocol for testing performance. Have a read of this article if you’d like to read up on the differences between UDP and TCP, and their pro’s and con’s.
In this article, I’ll be testing the performance of the network between two systems running Iperf, a RISC OS computer running as an Iperf server and a Linux system running Iperf as a client. The Iperf server address is 192.168.0.10
Below is a test you can run to test the bandwidth performance on your network, the result will show any spikes or drops as well as ‘jitter’ on the network.
This is quite handy when trying to pinpoint a particular device on a network as the source of an issue.
The below test is a single-connection bandwidth test, but Iperf will allow for multiple-connection testing as well as testing for packet loss and other metrics – use the ‘iperf -h’ command for a list of possible options.
Starting the Iperf server
To monitor the performance of TCP traffic on your network, begin by starting the Iperf server with the below command. As my RISC OS system is an Iperf server in this test, I run the command in the RISC OS command line by pressing F12 and entering the command in the box at the bottom of the screen.
iperf -s -i 1
This will bring up the below screen, which will be constantly listening for incoming connections and displaying results as traffic is sent from the client to the server.
—————————————————————————————— Server listening on TCP port 5001 TCP window size: 75.9 KByte (default) ——————————————————————————————
Initiating the test on the client
So on the client, which in my example is a Linux system, I used the below command. The same command will work on a RISC OS system running as an Iperf client.
In the below example, the time interval between tests is specified as 1 second, with the time for the overall test to be run set to 60 seconds. 192.168.0.10 is the IP address of my RISC OS Iperf server running on my home network.
iperf -c 192.168.0.10 -i 1 -t 60
This command will then send TCP traffic to the server – which will display a number of results at 1 second intervals.
Monitoring performance on the server
Once the command has been sent by the client, the server will then display results for the test.
—————————————————————————————— Server listening on TCP port 5001 TCP window size: 75.9 KByte (default) —————————————————————————————— [ 4] local 192.168.0.10 port 5001 connected with 192.168.0.2 port 2790 [ ID] Interval Transfer Bandwidth [ 4] 0.0- 1.0 sec 1.74 MBytes 15.3 Mbits/sec [ 4] 1.0- 2.0 sec 1.82 MBytes 16.2 Mbits/sec [ 4] 2.0- 3.0 sec 1.79 MBytes 15.7 Mbits/sec [ 4] 3.0- 4.0 sec 1.81 MBytes 15.9 Mbits/sec [ 4] 4.0- 5.0 sec 1.94 MBytes 16.6 Mbits/sec [ 4] 5.0- 6.0 sec 1.93 MBytes 16.3 Mbits/sec [ 4] 6.0- 7.0 sec 1.90 MBytes 15.8 Mbits/sec [ 4] 7.0- 8.0 sec 1.91 MBytes 16.0 Mbits/sec [ 4] 8.0- 9.0 sec 1.86 MBytes 15.7 Mbits/sec [ 4] 9.0-10.0 sec 1.93 MBytes 16.3 Mbits/sec
If we look at the results above, the average bandwidth is consistently about 16MBits/sec. There’s very little variation and there’s no obvious spikes or drops shown. This test was between two systems wired to a router on the same network.
I would expect results to show more variation if you were to run this test using a system of the local network or if you were using a wireless device as the server or client.
Should you be trying to pinpoint a route that is causing a performance issue such as high latency, then running Iperf between systems will allow you to track down the device where the latency is originating from. This is especially handy if you’re dealing with any kind of advanced routing within your network or should your traffic be running through a Linux router, or another type of router capable of running Iperf.
Iperf has a huge number of potential uses, and can be tailored to test for a whole host of network related issues. I’ll be following up this article soon with a guide to using Iperf to perform network stress-testing between systems, handy for testing the stability of public facing servers, web servers, game servers etc.