Saturday, 2 March 2013

My Apple & Raspberry Pi(e)

Apologies for the appalling title of this blog post, but hey, you're here! :) In this post I talk about my purchase of a Raspberry Pi (by devious means) and how I set it up as an iPerf server.

I have recently been reading lots about the Raspberry Pi mini/micro/teeny-weeny ( I don't know what the correct term is...) single board computer, which has been created by the Raspberry Pi Foundation in a attempt to promote the teaching of basic computer science in schools (according to Wikipedia).

I've been itching to get my hands on one for a while and finally came up with a great excuse to buy one and have a play with it. They're incredibly cheap (around £30 for the basic computer board), so I concocted a flimsy excuse about buying one to teach my son about computing. After letting him play with it (and get bored) for about 30 minutes, I quickly slipped in to my home lab where I will no doubt continue to 'evaluate' it.

The Pi is supplied with a flavour of Debian Linux on an SD card. I've got some background in playing with Linux and have hacked around previously with MySQL, perl, PHP and done a bit of web-coding, so the prospect of having a small unit with all of these features (and a LOT more) is (in a sad, geeky kind of way) quite exciting.

I bought a Raspberry Pi kit from CPC here in the UK which included everything I needed, apart from a plastic box to mount the board in, (so I purchased one of those too).

Here is what I received, which is incredible value for money (around £70):

It includes:

  • Computer board
  • 4Gb SD module
  • 2.4GHz WiFi NIC
  • USB hub
  • Keyboard
  • Mouse
  • Misc PSUs
  • HDMI cable

To be honest though, the only components I'll probably use going forwards are :

And, here they are assembled, ready to put in to my home lab (er, I mean to evaluate for my son's studies...):

Once you've initially built it, you need to hook it up to a keyboard and screen and watch it start-up. You'll be thrown in to a start-up dialogue (which I didn't capture...sorry) where you can enable an SSH server (well, that's the only option I used). Once you've done that, you can disconnect all of the peripherals and  plug it in to an ethernet port to start playing with it remotely.

Once I'd connected the Pi to my home lab network via an ethernet switch port, I knew it would pick up a DHCP address, but I wasn't sure what its IP address would be. So, I fired up my copy of Fing on my iPad and ran a quick scan to find out the connected devices. From the screenshot below, you can see that it successfully identified my Pi:

 The first time you SSH in to the Pi, you can login with the default username/password of pi/raspberry. Obviously, you are advised to change this to something a little more secure using the 'passwd' command. 

Here is what the SSH session looked like:

My initial 'task' for the Pi was to see how easy it would be to set it up as an iPerf server. This would provide me a method of getting an iPerf server running quickly, without having to fire up my home-lab Windows server every time I want to run some iPerf tests. So, I fired up my laptop SSH client and connected to the Pi and executed the 'sudo apt-get install iperf' command from the CLI:

As my Pi was connected to my network and had access to the Internet, it downloaded and installed the iPerf server software, as shown above (it literally took seconds to install).

Now that I had iPerf installed, I just had to run it from the CLI and I had a fully functioning iPerf server!:

On my iPad, I fired up my iPerf client (iPerf2) and pointed it at my new Pi iPerf server:

I was really blown away by how easy it was!

I also had a look around for an SSH client for the iPad and came up with WebSSH. Together with the iPerf2 client, this allows me to SSH to the Pi, fire up my iPerf server and then run the iPerf client from my iPad - all from one platform. This could potentially be a very useful tool out on site for surveying and testing:

I also investigated adding a few other applications and managed to install an Apache web server and the PHP programming language with similar ease. Having a web server that can be quickly and easily fired up will certainly be very useful in my home lab setup for testing and could perhaps be useful for on-site testing when deploying new networks.

My advice: get'll have hours of fun playing with it :) There are many more applications available for the Pi, thanks to the rich pedigree of its Linux heritage.

It also has a fully functional desktop environment where you can run applications in a more user friendly environment, but I'll leave you to find out more about that yourself :)

EDIT: Looking at the spec of the Pi a little more closely, the on-board Ethernet port is only 10/100. I suppose this could be a limitation if you are looking for an iPerf server that can test up to some of the higher WiFi speeds now available. For the foreseeable future though, I suspect that this will be plenty if looking at single-stream mobile devices, even with the advent with of 11ac.

Sunday, 17 February 2013

Adjacent Channel Interference

I was inspired to try a bit of experimentation following Keith Parsons' recent WiFi stress testing sessions, where he conducted testing on a number of vendor APs to observe at what point they collapsed in to a heap  due to traffic throughput.

I can't carry out anything as grand or detailed as Keith (I don't have his knowledege, brains or resources!), but I thought it might be fun to test some de-facto rules around the use of the 2.4GHz band for WiFi.

In summary, due to the bandwidth requirements of WiFi equipment, it recommended that the spacing of at least 22MHz is allowed between the channels being used in the 2.4GHz band. This is required for the bandwidth requirements of the older DSSS modulation scheme. The newer OFDM modulation technique requires only 20MHz of space, but for reasons of backward compatibility, the 22MHz rule persists.

The band itself is sliced up in to 11, 13 or 14 channels depending where you are in the world. Each channel is 5MHz in width, as shown in the diagram below:

To provide the 22MHz spacing required, it is generally recommended to use channels 1, 6 and 11, which provides a 25MHz spacing between the centre frequencies of the channels in use.

If these guidelines are not observed, then  due to the spectral mask of the WiFi signals, adjacent channel interference starts to occur, which causes errors across interfering channels and is generally a very undesirable situation. So, in a ideal world, everyone will play nicely and stick to the non-overlapping channels 1,6 and 11. Even neighboring networks that are using the same channels will co-exist quite well as they all play by the same rules defined in the 802.11 standard.

However, although this 'conventional wisdon is well established. I have never tested it for myself. So, I decided to fire up a couple of APs, a couple or iPads and an iperf server and see exactly what happened when I created my own adjacent channel interference.

My test  kit was:
  • a Cisco 2602 AP (nailed on channel 11)
  • a Cisco 1142 AP (varied across channels 6 to 11 during the experiment)
  • an iPad 2 running the iperf2 app
  • a 4th gen iPad running the iperf2 app
  • a Windows 2003 server running an iperf server
Both APs were nailed at a transmit power of around 10dBm. The test venue was just my garage at home (that's all I had!), with the kit laid out as shown below:

The distances were a bit shorter than I would have liked, but I guessed that if there were to be any effects to be observed, I should easily see them well with all devices in such close proximity.

Each AP has its own SSID and each of the iPads was configured to use the SSID of its nearest AP.

The 2602 AP and 4th Gen iPad were left untouched using channel 11 throughout the test. Channel 11 was selected, as it was the only channel that was not being used by any of my neighbors - see the inSSIDer screen-shot of the 2.4GHz band prior to testing:

The iPad 2 and 1142 AP were switched across channels with each test run. The first test run was on channel 6, the second on channel 7..etc. The purpose was to see the effect of throughout on the 4th Gen iPad fixed on channel 11 as the iPad 2 got closer and closer to its channel. Both iPads were running a TCP iperf test to the iperf server on the Windows 2003 server.

Each test was run 3 times to verify that I was getting consistent results.

The first test run was run with only the 4th gen iPad running the iperf test. This was to gauge the throughput of the iPad in the absence of any interference or competing load.

The results are shown in the table below (this shows the throughput on the 4th gen iPad - both iPads were simultaneously running an iperf test during each test run):

1142 AP Channel
Centre Freq
Freq Diff (Mhz)
Result 1 (mbps)
Result 2 (mbps)
Result 3 (mbps)

The results were quite surprising to be honest.

The baseline test-run with just the 4th gen iPad running a test showed a througput of around 35mbps, which is what you might expect for a single stream device under good conditions. So, no surprises there.

There were similar results when the iPad 2 was fired up and set to use channels 6 & 7. Throughput was pretty much the same, which is to be expected as we are maintaining the 20MHz spacing required for OFDM modulation.

However, at the 15MHz spacing when the iPad 2 is on channel 8, the performance falls off a cliff, averaging 2.6mbps. This was a real surprise. I expected a degradation, but not this level of impact. I repeated these tests a number of times (3 times, and, even repeating again at the end of my testing) to make sure they were not some type of anomaly caused by some sudden local noise source or other factor. But, the result remained the same.

For some reason, performance recovered quite a lot with a 10MHz spacing and dropped back off again with a 5MHz spacing.

Once we hit zero spacing (i.e. both APs on the same channel), things recovered, as both APs would both be playing nicely, effectively sharing the available RF bandwidth between them.

I must admit to being left a little confused by some of the results observed. It certainly underlines the impact on performance that may be experienced by straying from the conventional wisdom of using channels 1, 6 and 11. But, it does not explain why certain spacings have such a devastating impact compared to others.

One other point to note is that given the results shown above, it could be feasible to use a more concise channel spacing stragegy if just allowing a 20MHz spacing approach. This may have some merit if you have an OFDM-only environment, but if DSSS devices are present in neighboring buildings or floors. you will have issues. Also, if your neighbors have adopted the well-establish 1-6-11 channel plan, your new-fangled 1-5-9-13 (for instance) channel plan is going to suffer some pretty bad adjacent channel interference, which judging by the results above is a very bad thing...

Caveat: this testing is not definitive or done using particularly well controlled or scientific methods. I do not guarantee the validity of anything presented in this document. However, I'd be very interested in any feedback from others as to its accuracy from their own testing or real-world observations. Any advice on a better approach to better understand nuances of the results observed would also be welcome.

Friday, 15 February 2013

Aerohive AP121 Alternative Power Supply

Got yourself a free Aerohive 121 AP after a recent training course or webinar?

Got it home and found it's got no PSU!? Yeah, annoying isn't it...

Get yourself one of these 'bad boys' off Amazon - bought one this week and works a treat!

Disclaimer: if it blows your AP up don't blame me...mine certainly worked OK :)

*** Update 11th October 2013*** Works well for an AirTight C-55 AP too!