The RISC OS London Show 2016 takes place on Saturday, October 29th and it’s set to be another big show, with lots of exhibitors confirmed and hopefully a few interesting launches – developers tend to time new releases or major updates to coincide with the show so hopefully something juicy comes up.
The show will run from 11am to 5pm, with tickets being £5 at the door (and under-16’s free). Details of the theatre presentations are located here. The usual faces will be giving talks at the show – but perhaps the most interesting name one that list is Ident Computers, who are working on a BBC-Micro styled Raspberry Pi machine that will run RISC OS, MS-DOS and Windows 3.1 as well as Spectrum and BBC Micro games.
RISC OS Open will be showing off their recent developments at the show, including selling their usual range of goodies like media stick/cards with RISC OS on it as well as their RISC OS documentation range.
R-Comp will be in attendance with their usual range of computers and software. Andrew and Co. will undoubtedly be showing off their ARMX6 computers running on 4K displays as well as demonstrating their massive range of software and hardware.
CJE Micro’s will be flogging their usual wide range of wares – including their Raspberry Pi based laptop, the PiTop RO.
Amcog Games will be demonstrating their range of commercial games for RISC OS, Antony’s latest title, Xeroid, will undoubtedly be on display at their stand.
The full list of confirmed exhibitors, which have a few interesting names in there, is available here.
Many of you may be familiar with popular IT website The Register, if so you may be familiar with a recent series of articles they’ve published with images of computer error screens in public.
As you might expect, a good chunk of it consists of the dreaded Windows blue screen of death – but as well as Windows and Unix/Linux error screens they’ve included two Acorn errors seen in some interesting public places – a French airport being one of them!
So the first one is a standard Acorn boot-screen located at a British train station. The machine is stuck on the boot sequence and displaying errors instead of the usual train times.
This next one is a bit more interesting, a RISC OS 3 desktop with an on-screen error being displayed in a bus terminal in a Paris airport.
These sightings of RISC OS errors in the wild has got me thinking. There are still RISC OS systems out there in production environments, and although it may sound crazy to some people, it completely makes sense.
Generally, live systems are only migrated to newer versions and/or alternatives when the system in question regularly throws up technical issues or if it is subject to security vulnerabilities.
In RISC OS’ case, the operating system will just chug along with it’s tasks without much complaining. Errors are rare, especially when no changes or anything are ever made to the system.
Security vulnerabilities on RISC OS are also not as great a concern when compared to more mainstream operating systems, especially if you’re running a display system or some kind of server that dishes out data to the public.
Vulnerabilities on RISC OS are undoubtedly out there, but due to the small userbase I’d say the likelihood of someone taking the time to research a vulnerability and then exploit it is far smaller than these risks on other platforms.
Thirdly, from experience with rolling out updates on Unix-based systems – regular OS updates are a pain. Most responsible system admins will test the updates on a test system before rolling out to production servers, this is time consuming in itself and even more so when you encounter issues.
Now there are operating systems out there that are designed to be stable and long-running, OpenBSD is a great example of this, but with RISC OS there is rarely an update that is classed as a mission critical requirement – meaning your RISC OS system can just run and run. With the above points in mind, I’ve been thinking that there’s probably a lot more RISC OS systems in the wild that we imagine.
There’s probably systems we interact with every day that have RISC OS running in the background for no other reason than it just works and it doesn’t require any maintenance in most cases. Apart from in the instances shown in the images above of course.
So 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 192.168.0.10 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.
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 ————————————————————
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 192.168.0.10 -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 192.168.0.10, TCP port 5001 TCP window size: 1.00 MByte ———————————————————— [ 7] local 192.168.0.10 port 62401 connected with 192.168.0.2 port 5001 [ 6] local 192.168.0.10 port 62400 connected with 192.168.0.2 port 5001 [ 4] local 192.168.0.10 port 62398 connected with 192.168.0.2 port 5001 [ 5] local 192.168.0.10 port 62399 connected with 192.168.0.2 port 5001 [ 8] local 192.168.0.10 port 5001 connected with 192.168.0.2 port 42162 [ 9] local 192.168.0.10 port 5001 connected with 192.168.0.2 port 42163 [ 10] local 192.168.0.10 port 5001 connected with 192.168.0.2 port 42165 [ 11] local 192.168.0.10 port 5001 connected with 192.168.0.2 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.