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.
For a while I’ve had a Linux fileserver running at home which collects nightly backups of this site from the RISCOSBlog web server and also serves as a system that I can easily drop files into from various machines or from my phone when I’m out of the house.
It was about time I got my RISC OS systems in on the act too, and although there are options such as Sunfish, sftp and scp available for RISC OS – I decided to opt with rsync, which is far more efficient when transferring files, especially when you’re dealing with backups where most files are unchanged every time a transfer is made.
Rsync is highly configurable local and remote file synchronisation tool. It uses an algorithim designed to minimise the amount of data copied by only moving portions of files that have changed – which in the case of backups is normally only a few locations on a drive.
Available for install through the PackMan package manager as well as from the riscos.info site, Rsync is easy to install and once run can be accessed through the Task Window (F12). Just like the Linux variant, the tool has a command line interface only.
What I’d decided to opt for was to create singular a directory on my Raspberry Pi running RISC OS and set rsync so that it synced everything in that folder with my remote fileserver.
Rsync requires OpenSSH to be installed on both the local machine (in my case my Raspberry Pi) and the remote server, which for me was a system running Debian,
The process can be automated by setting up SSH keys to allow for both your RISC OS system and the remote server to talk to each other, the remote server will need to be configured so that a password isn’t required for the file transfer to proceed.
If you’re transferring to a Linux system then modifying the /etc/ssh/sshd_config file so that password authentication isn’t required when a valid SSH key is present should work. An SSH client such as OpenSSH or Nettle can be used for administering your remote server from RISC OS to do this.
Using the below command in the Task Window (F12) on my Raspberry Pi I was able to setup rsync to sync files located in the ‘Dropbox’ folder I’d created – although the command can easily be modified to sync another folder or an entire drive.
Pushing files to the remote system
The below performs what’s called a ‘push’ operation, this is because it pushes a directory from the local system to a remote system.
rsync -a /dir1 username@remoteserver:
Pulling files from the remote system
The opposite operation is ‘pull’. It is used to sync a remote directory to the local system. If the dir1 were on the remote system instead of our local system, the syntax would be:
rsync -a username@remote_host:/home/
After running both the above commands, your RISC OS machine will connect to the remote server and request that you authenticate. This will be through entering the password used by the username you’re accessing on the remote system unless you’ve setup SSH keys on both systems and configured the far end to accept password-less authentication.
Dual booting between Linux and RISC OS has become a lot easier over the years, with the Raspberry Pi it’s just a case of swapping the SD card with the operating system on it and rebooting the machine.
A cool litte tool from Elesar for their Titanium motherboard is GoLinux, which allows for Debian Linux to be booted into straight from the RISC OS desktop. Booting into Debian from RISC OS is just a matter of running the !GoLinux application.
Recently upgraded to version 1.02 – GoLinux now sets the sound system into a state that Linux expects to find it, fixing a previous issue that saw the Linux environment without any sound.
As well as running the utility on a barebones Titanium, it is also compatible with any Titanium-based computer, such as the Ti Machine from R-Comp or CJE Micro’s Rapido Ti.
GoLinux can be downloaded in a Zip file format free of charge from Elesar’s website.