SARS

Background

Ok, so not the Severe Acute Respiratory sort of SARS, but in fact a form of computer…

In fact, SARS is what I’ve nicknamed my new “supercomputer”. SARS stands for Small Array of Raspberry piS. I built this as I’ve also been interested in multi core computing, even before dual core and multi core chips were the norm (this is back in the pre-64 bit chips as well, when AMD Athlon chips were king!). Back then, the only way to get multi core operations was to either run lots of computers simultaneously or create a cluster (a Beowulf cluster can be easily setup and used by anyone using consumer grade hardware). Back in the days of SETI Classic, I was always amazed at the various crunching farms that people had created. Whilst I always fancied creating my own, I was always put off by the cost of it.

I’m a fire engineer by trade and a big part of my work involves modelling smoke spread and the ability criteria, using the program, FDS. Now FDS couldn’t really be called a true multicore program, however it does allow for simulations to be manually split over different cores, depending on how you create the model. This allows for the spreading of data over different cores and running the calculations in parallel. Normally, we split the model over a few cores (2-4 normally) and this will run fine on the hardware that we have, as the models will run perfectly on multi core machines where all the cores are local (I.e. we use multi core consumer machines, like the Xeon range of Intel chips.). However, the method of running these models multicore uses MPI - message passing interface, which is used in multi core clusters. Therefore, FDS can be run on a massive multicore cluster if required. So part of this experiment is to try and get FDS running multicore on SARS. There is a basic guide on creating and running an FDS cluster on the FDS website.

Pi’s

Since I saw the Raspberry Pi, I’ve always considered trying my hand at building a cluster. Nothing to large, like the University of Southampton’s cluster but something on a smaller scale so I could have a play with creating my own cluster. Speedwise it’s not going to blow anyone away (Phoronix created a twelve core ARM based cluster and benchmarked it against an Atom and i7 3770K - performance was reasonable, but not exciting), but as a learning exercise, it would be a good experience and perhaps a bit of fun.

So with some free time coming up, I decided it was time to get the Pi’s out and going. The end result is this mess!

Creation

So the shopping list for this build was simple.

• 2 x Raspberry Pi’s (Model B)

• 1 x Cubox

• 1 x Powered USB hub (not really needed but wanted for additional USB ports - see later)

• 2 x SD Cards

• 1 x Pi Case

This was to create small, dual core cluster with a single node for storage.

As you can see, all the computers are ARM based machines - another factor I wanted was low power. I love the idea of low powered machines and have always preferred a smaller quieter machine - that’s why I love the Mac’s (though the iMac isn’t quite as low powered as I expected!) and I like the idea behind the Intel NUC’s. Obviously, some factors have to be taken into account - such as I’m not going to get i7 performance(!) but the whole ARM based computer “revolution” is in my eyes, pretty exciting (after all, most electronics we use are ARM based, such as phones and embedded devices). The Phoronix cluster mentioned above, draws 30W of power. This cluster draws about 10W.

I choose a Cubox as the storage node for the cluster rather than another Raspberry Pi because I fancied trying one! To be honest, I felt the faster network adapter would benefit the cluster but I’m also going to use the Cubox as a NAS device for my local network. So whilst it’s the same clock speed as the Pi’s (the default Pi clockspeed that is…), it has double the memory available (1GB rather than 512MB) and a 1Gb network link, rather than 100Mb (though due to restrictions, it’s not a full Gb link) so it should perform slightly better than than a Pi in the same position.

Setup

Setting up the cluster required some messing around. The Pi’s were easy to set up. Of the ARM based boards I’ve tried, the Pi is by far the best supported and easiest to get going.I just downloaded the latest version of Raspbian (I’m a Debian fan) and wrote to the SD Card and away you go.

The Cubox was a bit more involved and a bit more difficult. Solid Run advertise it as unbrickable, which is good, because I pretty much bricked it as soon as I got it, trying to update the firmware!

Anyhow, once I got the Cubox running Debian and installed to the latest firmware, I set it up as the Master node.

Cubox

The Cubox is a small, fairly powerful machine. I was interested in how it compared to the Raspberry Pi - it’s more expensive (£100), compared to the Pi (£30) but does it give more bang for the buck? I thought I’d test it using the Science benchmarking suite from Open Benchmarking. This makes it somewhat easier to test. The Science benchmark was chosen as this was to run FDS software, which performs the same kind of tests as the science benchmarks will have the software run.

As can be seen, the Cubox contains an ARM v7 CPU and the Pi is an ARM v6 - a small difference (the Pi is also overclocked using the default overclocking settings). The Cubox is at 1GHz (not shown as OpenBenchmarking didn’t pick it up). Either way, it has additional RAM over the Pi and I thought this would come in handy. I ran the benchmarks (and also compared it to an old Pentium M laptop I had lying around). The results are shown below.

We can get a close look at the Pi Vs Cubox devices as they’re fairly similar and the Pentium can be seen to outstrip them, even considering it’s ages.

As can be seen, the Cubox is faster, but not by a significant margin - not perhaps, enough to consider the cost difference. It should be pointed out that the Raspberry Pi is also nicer to work with and whilst the Cubox is sold as impossible to brick, the Pi doesn’t have any firmware to brick and therefore is a far more user friendly machine to work with.