|
|
| Beta! | About us | Contact | Submit news | RSS | Twitter | Webspace | Tech docs | Downloads | BBC Micro | Gallery | Wallpaper |
|
Adventures with a Lego-cased A7K web server By Peter Howkins. Published: 21st Nov 2008, 19:49:07.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.The contenders To start, my Acorn A7000, manufactured in 1995. Its vital statistics are:
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:
Services provided 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:
The following servers have been available in the past but have proved difficult to find for testing purposes:
Stability 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. Environmental factors 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. Remote management 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:
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. Remote monitoring 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:
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
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:
And here's the utilisation of underlying network transport, maximum theoretical throughput, excluding ethernet, IP, TCP and HTTP protocol overheads:
It appears possible that the comparison PC is being limited by availabilty of network bandwidth. An upgrade to 1GBit/s networking might prove useful. Conclusions 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. Links A7000 in a Lego rackmount case * As a declaration of interest, StatusDaemon was written by Drobe editor Chris Williams. Discussion Viewing 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. |
Login
Create a new account Forgot your password? Search this website
This week's poll
Featured articles The weekend's RISC OS event has been and gone and we've got the rest of our lives to look forward to. Here's a round-up of extra news and Drobe's show-related coverage and some photos taken from Wakefield 2009 - plus a video from the show floor. 16 comments, latest by AW on 29/4/09 7:41PM. Published: 27 Apr 2009Picture exclusive - This grainy photograph shows a port of RISC OS 5, sourced from the RISC OS Open project, running on a Beagleboard - a device powered by a 600MHz ARM Cortex-A8 processor with a built-in graphics chip. The port, developed by Jeffrey Lee with help from Uwe Kall and ROOL staff, is seen as a major breakthrough for the shared-source project as it proves the OS can be ported to new hardware without the need for a large team of engineers. 75 comments, latest by rjek on 30/4/09 3:15PM. Published: 25 Apr 2009It can be a pain when someone sends you a file that can only be opened on Windows, Mac OS X or Linux - but with the help of a free-to-use website and NetSurf, Paul Stewart reveals how these documents can be viewed on RISC OS. 6 comments, latest by AW on 8/5/09 12:12AM. Published: 19 Apr 2009Useful links News and media:Iconbar • MyRISCOS • ArcSite • RISCOScode • ANS • C.S.A.Announce • Archive • Qercus • RiscWorld • GAG-News Top developers: RISCOS Ltd • RISC OS Open • MW Software • R-Comp • Advantage Six • VirtualAcorn Dealers: CJE Micros • APDL • Castle • a4 • X-Ample • Liquid Silicon • Webmonster Usergroups: WROCC • RONE • NKACC • IRUG • SASAUG • ROUGOL • RONWUG • MUG • GAG • RISCOS.be Useful: RISCOS.org • RISCOS.info • Filebase • NetSurf Non-RISC OS: The Register • The Inquirer • Apple Insider • BBC News • Sky News • Google News • xkcd • diodesign |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Recently logged in:
Becky •
martin •
jmb •
killermike •
DaveW •
VinceH •
bluenose •
egel •
rjek •
bavison • Stats
© 1999-2009 The Drobe Team. Some rights reserved, click here for more information | Powered by MiniDrobeCMS, based on J4U
"Leaking tit bits creates rumours, confusion and often mangles facts"
Page generated in 0.1036 seconds.
The Mico should have had more performance that an A7000, the Mico being closer in design to an A7000+