Simmers

Some pictures of our GTC accommodation

2008-10-09T18:08:00.005+02:00

The outside of the house

The front of our house

Our front door

The back garden (braai place coming soon)

Our bikes (note the mudflaps!)

The inside of the house

The large kitchen

The small kitchen

Victorian window bling

Our ethereal blue and timed corridor light switches

The dehumidifier drying the floor after a water pipe burst!

Our spacious room (number 11)

The bed

The bathroom fittings

Cupboards and storage

The working wall

Miserable weather, bicycles and 33 St. Margarets

2008-09-30T22:40:00.017+02:00

Yesterday, the reality of the British weather hit. Kerry and I have had ridiculously sunny days since our arrival in Oxford. However, the clouds over Oxford yesterday loitered somewhere between "I'm about to rain" and "let's drizzle a little to catch those people out who didn't bring umbrellas". Thankfully, however, it was not cold.

We decided to have lunch today at Green Templeton which, in hindsight, was a fantastic idea. Kerry, who is used to res meals, has become accustomed to fighting for scraps of oily food in a hall filled with hungry academics and little order to speak of. In contrast, Green Templeton had a chef, three course meal and a waiter to dish out food and clear plates. Oh my god - the opulence. Naturally, Kerry is loving every minute of it. In addition, the food was scrumptious and really cheap - it worked out to about £4 in total for soup and a cold meal for both of us!

At lunch we met a few of the Oxford freshers. Sam and Vivec (have I spelled that correctly?), who are each studying Global Health and Pharmacology respectively are keen to join the College football club. I'm not sure if I'll be entitled to join them, but if I can it would be really great. Although Jackie, the MCR of Green Templeton, said that I might be eligible if I join pay common room fees. I shall investigate...

After lunch we dashed off up the road to check out the inside of 33 St. Margarets (our home for the next year). Turns out there are 13 rooms and we are, in fact, on the top floor facing the back garden. The house has a laundry room and two large kitchens to share. Best of all, our en suite room is ridiculously spacious.

In the afternoon I visited Vicon to see where I'll probably be taking up an internship over the next 6 months. The offices are really great - there are lots of friendly people working with cool media equipment. I look forward to starting there next week.

Today we're going to Oxford University orientation in town. It starts at the examination rooms on Queen Street and we're not quite sure what exactly will happen. Thankfully, the weather seems to have picked up a bit.

Last night our bikes arrived and we're both pretty keen to test them out. Since orientation begins at 8.30 this morning and we only have a basic familiarity with the Oxford road network, cycling through is a little out of the question.

Oxford, finally.

2008-09-29T11:24:00.008+02:00

On Friday afternoon Kerry and I arrived (after a grueling 20+ hour trip via Johannesburg and Doha) at London Heathrow airport. Qatar was an amazing airline - their legroom was substantial, service was excellent and food was both tasty and filling. Apart from the duration of the flight, pretty much everything else was A+.

The day we arrived happened to be my mom's birthday, so that evening Adrian treated us to an incredible supper at an Italian restaurant in Headington. Both Kerry and I were so tired from all the traveling, we crashed very early and slept well that night.

Green College

The next morning we travelled into Oxford to mainly smash some administrative chores, but also to see Kerry's college (Green Templeton) and where we'd be living for the next six months. Green College was incredible. The gardens were immaculately kept and the building screamed of Coloumbian druglord money. Even more impressive, however, was the residence at which we will be staying - a recently restored Victorian mansion with a HUGE back garden on St. Margarets Rd, a 10 minute walk from Oxford centre.

St. Margarets Rd

On Sunday Kerry ordered her first Mac, which we're both super excited about. It's so much cheaper buying it using the higher education discount - around £713 vs. £829 normally and £880 in South Africa. The UK apple store offers a back to school deal, where you can effectively get an 8 GB iPod nano for free when you buy a Macbook, which is totally cool. Naturally, Kerry seized the offer and we should receive the bounty in the next week or so.

As some of you might know, Oxford is a town dominated by cyclists. Owing to price of petrol and the fact that you cannot drive into central Oxford, it makes sense to use bicycles to get from one place to another. Today both Kerry and I ordered "town bikes", which will be delivered today or tomorrow. These will give us both a little more freedom and excercise. Thankfully, the weather at the moment is great - we had a braai (yes a braai, not a barbeque) last night - so cycling should not be too hard on us!

Networking/Wireless hardware

2008-06-29T00:40:00.009+02:00

Perhaps it is related to having a deep interest in the field of computing, but for a long time I have been fascinated by the arcane field of microelectronics. While I don't claim to have any real ability in this field, I have been known to brandish a soldering iron periodically. Perhaps my greatest claim to fame is using JTAG to debrick a Linksys WRT54G (see the picture on the left) after a bad firmware upgrade. Red Butto n eventually asked me to help me out with a few of their bricked devices, which is quite cool.

Despite my very small bedroom, I have a remarkably large quantity of broken ADSL routers, spare WiFi access points and general electronic bits and pieces I have collected over the years. I accumulate it thinking "one day I'll get round to investigating this device", which seldom happens.

Over the years Telkom has managed, with the help of Marconi SA, to coax unsuspecting ~~victims~~ customers into purchasing various networking-related hardware. I made the unfortunate mistake of trying to upgrade the firmware of the ADSL Router Pots product, after it kept dropping our connection. Despite following the instructions precisely and taking every precautionary measure, the upgrade failed and the router b0rk3d.

As any practicing geek would, I opened up the router and found out that it has a Motorola XPC850ZT50BT microprocessor, whose datasheet can be found here. Apparently, this is what the device is capable of doing:

The MPC850 is a versatile, one-chip integrated microprocessor and peripheral combination that can be used in a variety of controller applications, excelling particularly in communications and networking products. The MPC850, which includes support for Ethernet, is speciﬁcally designed for cost-sensitive, remote-access, and telecommunications applications. It provides functions similar to the MPC860, with system enhancements such as universal serial bus (USB) support and a larger (8-Kbyte) dual-port RAM.

Now, wouldn't it be awesome to do exactly what the OpenWRT /DD-WRT people did with the WRT54G and leverage the power of a ultra lightweight Linux kernel (perhaps based on uClinux) to build a small, custom firmware for this device. You could possibly revive the functionality of the device or even think of creative alternative uses (like for a robotics project of sorts).

Another interesting device produced by Telkom/Marconi team was/is the ADSL WiFi Router (see picture on the right). This router was kindly donated to me by my supervisor at UCT. As far as I can tell, it is based on the Conexant AccessRunner ARM microprocessor, which is commonly used in USB ADSL modems. There are a number of interesting unused header pins marked JU1 on the board - perhaps it's a JTAG, serial or (very unlikely) USB interface.

One would be inclined to think that the ADSL Wifi Router makes use of an onboard or Mini-PCI wireless radio, like the Linksys WRT54G. However, opening it up revealed a Senao NL-2511CD Plus EXT2 cardbus card, based on the Prism 2.5 chipset. The cool thing about this cards is that, when they first came out, they were one of very few cards that could be switched to promiscuous mode to sniff wireless traffic (you didn't have to be associated with an access point to see the traffic). If I recall correctly, that was a prerequisite for WEP cracking. Nowadays, there are plenty cards that can achieve this.

On a side note, if you're planning to do some serious wifi hardware purchasing soon, please take note of the following three points:

Try not to buy pre standard 802.11n or IEEE 802.11n draft hardware. Firstly, it is not fully-guaranteed to operate with the final standard (it relies on firmware updates to fill in the missing gaps) and it really goes against what stadardisation tries to achieve as a whole.
The actual card manufacturer (Belkin, Linksys, Apple etc.) tends to count less than the radio chipset manufacturer (Atheros, Broadcom, Intel, RaLink, Realtek, Prism etc.). Intel and Atheros have really good open source support.
I've worked with Broadcom, Atheros, Intel, Prism and Ralink hardware. I'd recommend either the Atheros or Intel chipset over anything else. For Atheros the MadWiFi project provides a really good set of drivers for most cards (the modern ones tend to lag slightly). To check if a specific card is based on an Atheros chipset, check this compatibility list. Here's a link with more information about Linux drivers for Intel's wireless cards.

I went a little off the topic there, so I'm going to steer straight back on course. I'd like to pursue hardware tinkering more seriously, so I'm appealing for more information on reputable forums or IRC channels where relatively new people to the field can exchange ideas and learn. Please leave a comment if you know of any resource for me. Thanks :o)

Part I: WiFi, DCF and performance issues

2008-06-28T21:51:00.011+02:00

Right - as promised, today I shall attempt to explain what I have been doing for the last 18 months as part of my Master's research. My work is in the field of wireless networking and is, basically, a performance study of a channel access control protocol within IEEE 802.11. More specifically, I am looking how this protocol performs in Internet access networks (like wireless Internet cafes etc.). In order to do this, I shall perform a number of experiments using a test network, kindly provided by research lab (there's a picture of it on the left.

Imagine you put lots of people together in a room and tell them to talk. Normally, there is some form of structure to the conversation and people contend for speaking rights, usually by waiting until there is some idle time in the conversation. If everybody spoke at once, most of the chatter would be indiscernible from the chatter next to you.

In single channel wireless networks things happen in the much same way. Computers contend for access to a shared wireless channel (they can't all just transmit when they want to) using some medium access control mechanism. There are two broad types of control - (1) contention-based and (2) contention-free. We've already looked at (1) above. In (2) the "conversation" is regulated by some central manager.

IEEE 802.11 (you probably know this by it's commercial name, WiFi) is a standard for wireless networks. Basically, it provides a guide for manufacturers so that they produce interoperable products; it would really suck if your laptop could only connect to certain wireless networks. IEEE 802.11 normally operates in one of the license-free channels in the 2.4 GHz or 5.2 GHz ISM bands. However, since Bluetooth, microwaves and some cordless phones also operate in this band, there's normally lots of interference to contend with. To illustrate this problem, here are two snapshots from a WiSPY 2.4 GHz spectrum analyser. The first image shows a 30 second recording of near-perfect channel conditions - there is some mild activity on channels 6 and 12. In the second image I turned a microwave on... I think the image speaks for itself.

Technically, IEEE 802.11 specifies both a contention-based and contention free mechanism to coordinate access to the channel, which they call DCF and PCF. However, some naughty companies fought over the "ambiguous" details of PCF, which resulted in it never being implemented in any products.

Wireless radios have one major problem - you can't transmit and receive at the same time. Even if you could, the signal coming out your antenna would be so powerful that it would be difficult to hear any signal other than your own. Wired networks don't have this problem. In fact, you are able to detect and recover from errors much quicker in wired networks, because of this. In contrast, wireless networks use collision avoidance strategies to try and limit the number of collisions that occur between stations.

DCF is what most WiFi networks use these days (see the figure on the right). In 2005 the IEEE made a cooler version called HCF, but it's not used widely enough yet. DCF stands for the Distributed Coordination Function and it's quite a clever method of coordinating channel access. Without going into too much detail, all that DCF does is enforce a certain amount of waiting time before it attempts to transmit information. The random waiting time x(0) is chosen uniformly in the integer range [0, 16] or [0, 32] depending on what type of hardware you have. The station now counts down for x(0) ticks (the time of each tick is really small - either 9 or 20 microseconds, again depending on your hardware). If another station starts transmitting at any point this 'back-off counter' is suspended and resumes again when the channel is sensed idle.

When the counter reaches zero the station tries to send the data. If, after a little bit of time, there is no response from the receiver the sender assumes that a collision took place. To recover from this, a new waiting time x(1) is chosen from an integer range that is double the size of the last one. The station then backs-off again for x(1) ticks and attempts to transmit. The integer range is doubled until it's size in 1024. Thereafter, it stays at that size until a maximum retry counter is met, which normally happens after 5 to 7 retries. If it collides on the last attempt the data is dropped - you have to really be stressing the network to get to this point!

Naturally, this is only a brief intro to DCF. I haven't even talked about the inter-frame spaces (SIFS, PIFS, DIFS and EIFS), all of which are crucial to the operation of the protocol - they enforce a hierarchy of actions, viz. they enforce DATA-ACK sequences complete before new DATA-ACK sequences start. There is also an optional four-way handshaking mechanism, in which a station sends a curt warning (called a request to send message, or RTS) to stations in the area warning about an upcoming transmission. The receiver immediately sends a brief clear to send message, or CTS, back. The extra two messages tell stations in the area to keep quiet for a while, so as not to crash the party.

Now I could waffle on four hours about DCF (my remaining friends will vouch for that) but to cut straight to the chase - DCF adds lots of overhead to the network. When combined with all the headers that are appended to messages, the random back-off process, control packets (ACK, RTS and CTS) and inter-frame spaces used in DCF eat a huge chunk out of your available network capacity. To give you an idea, modern WiFi radios can transmit data at up to 54 Mbps (megaBITS per second) and control packets at up to 24 Mbps. The absolute maximum performance you can get is heavily-dependent on the amount of data in each message. However, in typical cases a standard-abiding network will peak at around 45% efficiency. This means that your network will run at 24.3 Mbps, which is just over three megaBYTES per second! Now this is shared amongst all users in the network. For example, an 800 MB XviD movie will take 5 minutes to transfer accross a wireless network in these optimal conditions, which is significantly longer than on a regular wired network.

Storage : 1 Megabit = 1024 Kilobits = 1024 x 1024 bits
Transmission : 1 Mbps = 1000 Kbps = 1000 x 1000 bits a second

Now, hopefully you understand why wireless networks run so slowly when compared to their wireless counterparts. Although IEEE 802.11n (an upcoming standard revision) promised to provide much faster transmit rates, the problem of channel coordination remains. I think it's clear why we need models to predict IEEE 802.11 performance - deploying

Up next in Part II : Modelling Wireless Internet Traffic

Time management and when to say "No, thanks"

2008-06-27T12:11:00.004+02:00

I'd like to start with an apology to all my computer science friends who will, no doubt, be rolling on the floor laughing at me as they read this. The reason I say this is that I am the ultimate anti-blog zealot, having once been quoted as saying

The sum total content of blogs is a chronic misallocation of valuable terabytes of storage media and bandwidth.

My reasoning was straightforward - most blogs simply reveal another day in the life of somebody who loiters somewhere between "acquaintance" and "friend" to you. Also, it's another example of how technology and the Internet is making it to easy for all of us to cocoon... but that is a rant I will reserve for another day.

My justification for adding my ten cents worth to the steaming pile of festering internet scrap is simple. Imperial College requires that I keep a textual record of my movement for the next three years in either a traditional "burn-down-the-amazon-rain-forest" (diary) or "leverage-the-power-of-mass-Internet-storage" (blog) form. After years of computing my handwriting has deteriorated into something that looks more like hieroglyphics than English (even GPs would be impressed). I think my choice was obvious.

I thought I'd begin my blog with a simple problem that I have had over the last two years - time management. During postgraduate study one is constantly bombarded with fascinating ideas, projects and, periodically, employment opportunities. In an ideal world one would be able to simply push the pause button on life's remote control and spend some "time" on something fun - for example, writing the Bayesian prediction engine for my Honours project. Unless somebody invents a remote control that could make a person or their surroundings travel really fast (~ the speed of light) we are forced to surrender to the sad fact that there is an opportunity cost to working on other projects. If I do not wish to join the three year Master's plan reluctantly offered by the UCT Computer Science department, it is my duty to learn when to say "no, thanks".

In addition to the chlorophyll project, I was recently offered an opportunity to work for a really cool Internet-based start-up in South Africa / London. Sadly, I had to decline the offer - it was clear that my time frame could not accommodate their project in addition to my Master's experimentation and write-up. This sacrifice was clearly not enough, so life threw a new-ish CUDA SDK, the TS-7800 SBC (pictured right), DoTA (always), Battlestar Galactica and protein folding to distract me...

OK - that's enough of an introduction. Of late, I seem to be getting many people asking me what my Master's work entails. In my next post I shall attempt to explain this in a funny and witty manner. I will probably fail dismally, as there is a finite and negligible amount of happiness that can be milked from IEEE 802.11 and internet workload modelling.