Adventures with a Lego-cased A7K web serverBy Peter Howkins. Published: 21st Nov 2008, 19:49:07 | Permalink | Printable
Having previously built desktop and laptop cases of out Lego bricks, model building Peter Howkins has turned his attentions towards crafting a slim box to slid his A7000 into a rack, alongside other rackmount servers. Having pieced together the housing, Peter puts a legacy RISC OS machine through its paces as an internet-facing server.As an offshoot of my cunning project to create a 1U size case for my A7000 out of plastic Lego bricks, I pondered the suitability of actually running the ARM7500-powered computer as a server. This is 13-year-old hardware so I rightly can't expect modern performance, but can the A7000 fill some sort of low-power, power-efficient server role? I decided to investigate this by testing various bits of server-related software available for RISC OS, having assumed the computer will be used as an unattended machine in a rack hooked up to a network. As it will not have a monitor or keyboard attached to it, I also decided to attempt to address the need to monitor and control it remotely over said network.
To start, my Acorn A7000, manufactured in 1995. Its vital statistics are:
- 32MHz VLSI ARM7500 processor
- 68MB RAM, 4MB onboard, 64MB SIMM
- RISC OS 3.60
- EtherH network card
- IDE-to-Compact flash card adapter
- 2GB Compact Flash 'hard disc' with a RISC OS 4.00 softload from Pace
- Custom 1U rackmount case, made from Lego, with internal fluorescent tube light and no fans.
Pictured is the A7000 server in the Lego rackmount case, sitting in a rack, and, right, dismantled. Click on a thumbnail for a full image.
I intended to compare the A7K with a PC, namely this HP dx2000, manufactured in 2004:
- 2.8GHz Intel Pentium 4 (Prescott A)
- 1GB RAM
- 40GB IDE hard disc
- Solaris 10 operating system
- Standard desktop ATX mini-tower case
Compared to other server platforms, RISC OS (as a primarily desktop OS) offers fewer services. However several internet and file/print sharing services are available, such as HTTP, FTP, SMB, NFS and Access(+). For the sake of this article, I'll only be comparing HTTP servers, of which RISC OS has several. A HTTP server works by setting itself up and then waiting for web browsers to send it requests for pages, images and other documents. The web server locates and serves the documents, which could be stored on a hard disc or generated on-the-fly or a mixture of both, by sending them back to the clients, which then display or do some other work on them.
Here are the HTTP servers available:
- Webjames - 0.48 - 05/05/2007 - A largely capable web server with support for CGI, SSI and PHP (available as a separate or combined download). Freeware.
- Serviette - A recent web server, supporting Python scripting. Commercial.
- NetPlex - 2.01 - Supports CGI scripting in Perl, PHP and SHTML. Commercial.
- h11p - 1.31 - 11/06/2006 - Included only for my own amusement. It's a web server that measures just 1KB in size and is not even HTTP/0.9 compliant. Freeware.
- InetD/micro_httpd - Included only for my own amusement as it's my unfinished InetD with a port of Acme's micro_httpd. Unavailable.
The following servers have been available in the past but have proved difficult to find for testing purposes:
- HttpServer - A simple server, written in BBC Basic, by Stuart Brodie. Freeware.
- DeltaNet - A large package of servers including HTTP. Shareware.
- AlphaNet - A commercial development of DeltaNet. Commercial.
A primary concern of a remote server is the stability of the software and hardware. Having to reboot a server in normal operation should not be expected because, among other reasons, services are unavailable during this process. After some initial concerns, RISC OS proved stable enough to provide five days of up time without issues and may provide more if I were to test it more thoroughly.
Adequate cooling needs to be provided to any server with heat sensitive components. For the A7000 in this project, I replaced the standard issue hard disc with an IDE-to-Compact Flash adapter and a Compact Flash card. Cooling requirements for the server are not on the radar as all the components run at room temperature even under load; there's simply no need for a fan or such device. Power usage of the A7K, being a modest ARM-driven machine, should ideally be low, or at least offer a good power/performance trade off. The power draw measured on the A7000 was 11W while under web serving load and 10W idle. My comparison desktop PC pulled 99W under similar load and 75W idle.
Being able to control a machine remotely is important in a server product so that changes can be made and fixes installed without having to be on-site. Racks of servers are predominantly locked away in large warehouses, where they can be closely coupled to internet backbones, kept in cool and machine-friendly conditions and watched over by security guards. The downside to housing machines in data centres is that it's a chore to go on-site to fix them, hence the requirement of stability and remote management.
Here's what I uncovered:
- SSH - This provides a secure and encrypted method for connecting to a remote host, but such a service is not available for RISC OS, and also generally unsuitable due to the graphical nature of RISC OS applications. This is the de facto standard for remote access on UNIX and UNIX-like OSes.
- Telnet - A telnet server exists for RISC OS. One again due to the graphical nature of most RISC OS programs (and their configuration) coupled with telnet's extremely poor password security I would not recommend it.
- VNCServer - A VNC server, for 26bit and 32bit RISC OS machines, provides 'slow' access to the RISC OS desktop from pretty much any client OS available. Due to its graphical nature, it's easy to configure and control all programs. VNC works like Windows Remote Desktop, in that you can remotely view the server's desktop and interact with it using the mouse and keyboard connected to the computer running the VNC client. However by default VNC security, whilst considerably better than telnet, is poor and susceptible to determined malicious folk. Appropriate firewall rules to prevent access from most IP addresses would be advised.
Perhaps as a last resort this project would benefit from the server being attached to a network-accessible power rail, with the ability to remotely power cycle it - effectively switching it off and switching it back on again when a problem occurs using a power supply that's connected to the network.
Being able to see the state of the server, or even if it's running at all is useful. The normal protocol used for this purpose is SNMP, of which no RISC OS server is currently available. Ideally the solution would need to provide the following information live:
- CPU usage
- Memory usage
- Disc space usage
- Network bandwidth usage
The closest RISC OS software I can find to providing this is Chris Williams' Status Daemon* which may provide enough information.
Benchmarking of HTTP servers
Each of the server software packages were benchmarked one by one on a local area network with one ethernet switch between the test host (a PC running Linux Ubuntu 7.10) and the target machine. All tests were run using 'ab' (Apache benchmark), which measures how many requests for web pages the server can handle per second. The Linux PC was therefore told to fire requests for 1,000 1KB and 100 25KB pages at each of the HTTP servers. Two levels of concurrency were also used, one being one request sent at a time and five being that many requests sent simultaneously. In the real world, web servers are constantly bombarded with multiple requests at the same time and this tests the software's ability to handle multiple clients.
The RISC OS servers were also allowed to run and serve pages stored on the RAM disc. On RISC OS servers, logging of requests was disabled. The comparison PC was running the Apache 2.2.6 web server.
Example 'ab' usage:
ab -n 1000 -c 5 http://192.168.2.60/1k.html
|Server||Page Size||Storage||Concurrency||Req/s||Transfer Rate (KB/s)|
|RISC OS - A7000|
|WebJames||1 KB||RAM||5||17.86||19.64||Fastest RO Req/s|
|WebJames||25 KB||RAM||5||9.08||226.97||Fastest RO KB/s|
|Solaris - PC|
|Apache 2.2.6||1 KB||Disc||1||1587.25||1949.14|
|Apache 2.2.6||1 KB||Disc||5||2353.66||2890.30|
|Apache 2.2.6||25 KB||Disc||1||340.57||8592.56|
|Apache 2.2.6||25 KB||Disc||5||445.82||11248.13|
It seems that running and serving from RAM disc provides a 5 to 10 percent performance boost for all the RISC OS servers, except for some cases of h11p. WebJames comes out as the fastest RISC OS server, managing up to 17 requests a second or 226KB a second, depending on the size of the page. Unsurprising, the 2.8GHz Intel-powered machine blew the A7K out of the water with 2,353 requests a second or 10MB per second. Given the low-power consumption of the RISC OS platform, and the particulaly high consumption of the P4 in the comparison machine, I calculated the following metrics to see if the little A7000 fared better:
|Requests per Second per Watt|
|RISC OS (Web James)||11W||17.86||1.62|
|Solaris (Apache 2.2.6)||99W||2353.66||23.77|
|KiloBytes per Second per Watt|
|RISC OS (Web James)||11W||226.97||20.63|
|Solaris (Apache 2.2.6)||99W||11248.13||113.61|
And here's the utilisation of underlying network transport, maximum theoretical throughput, excluding ethernet, IP, TCP and HTTP protocol overheads:
|Server||NIC Type and Max throughput||KB/s||% of Max|
|RISC OS (Web James)||10 Base T (10 Mbit/s 1280 KB/s)||226.97||17.73%|
|Solaris (Apache)||100 Base T (100 Mbit/s 12800 KB/s)||11248.13||87.87%|
It appears possible that the comparison PC is being limited by availabilty of network bandwidth. An upgrade to 1GBit/s networking might prove useful.
I'll be blunt. Using 13-year-old hardware for sensible things is a bad idea. My A7000 offers slow performance for low absolute power requirements. However it appears that even the famously power inefficient Pentium 4 architecure in a 4-year-old PC out-performs it significantly in power-based metrics. Looking beyond the fact that the meaty P4 can happily cope with over 130 times the number of requests for pages than the A7K, it still delivers more performance per Watt.
A case could be made that an A7000 could be suited to a low-traffic website when the server would spend most of its time idle. However an even more efficient solution would be to virtually host such a website on a server with other sites hosted on as the small site would barely take up any additional power at all when hosted alongside other sites on a PC solution.
The increase in performance when using RAM disc to serve files suggests that RISC OS may benefit from a cache of recently-accessed files, which would be held in RAM. It is faster to fetch a file from memory than from a hard disc or even Compact Flash and most modern operating systems employ this technique of disc caching.
However I'm not entirely dismissive of the use of RISC OS hardware as a server, and am interested in running future benchmarks on a StrongARM RiscPC and an A9home. As I expect the increase in performance (without
the corresponding increase in power requirements) may prove more competetive. But in fairness more power efficient PC architetures such as Intel Core2 and Intel Atom should also be investigated.
A7000 in a Lego rackmount case
* As a declaration of interest, StatusDaemon was written by Drobe editor Chris Williams.
Previous: Iyonix emulator mulled by developer
Next: Prototype affordable Braille display in development
DiscussionViewing threaded comments | View comments unthreaded, listed by date | Skip to the end
Please login before posting a comment. Use the form on the right to do so or create a free account.
Search the archives
Today's featured article
Silence is golden
Knowing how to tell your RiscPC to shut it
22 comments, latest by Rien on 7/8/04 5:56PM. Published: 1 Dec 2003
New release of family tree file editor
Version 2.02 of freeware GEDCOM editor Prune
Discuss this. Published: 27 Apr 2007
News and media:
RISCOS Ltd •
RISC OS Open •
MW Software •
Advantage Six •
CJE Micros •
Liquid Silicon •
Chris Why's Acorn/RISC OS collection •
The Register •
The Inquirer •
Apple Insider •
BBC News •
Sky News •
Google News •