Features

Throughput: what you get from WiFi is not what is written on the box!

The news that Linksys is about to launch a "superboost" WiFi router has astonished a lot of customers, who are asking "Why is it so slow? You said it was 'only' 36 megabits per second - but full-speed 802.11g runs at over 50 megabits!"

The reality of WiFi is that the original 802.11b standard runs at a nominal 11 megabits per second, but that you'll never get more than five megabits of data through it, even if you're the ony user. And the newer 802.11g standard runs at a nominal 50 megabits, but again, you aren't going to get more than 22 megabits of "data payload" through the network - which is, of course shared.

Why aren't these numbers the ones that the industry quotes?

Big numbers, as they say, make for big sales. It's normal for notebook PC makers to claim "three to four hours of battery life" when everybody who uses a portable PC knows darned well that you'll get two hours. The reasons is that if one supplier quotes a certain number, it makes everybody else look bad if they quote something else; and the battery figure is one derived from a magazine's battery benchmark.

It's supposed to be based on "typical use" which is fair enough. It assumes you'll turn aside from the keyboard to discuss matters with colleagues; or that you'll stop looking at the display while talking on the phone, or that you'll be out of the room for ten minutes here and 20 minutes there. Unfortunately, when you've got a lot of work to do, you need to know what the actual battery life is with the disk spinning and the display lit and the processor running several tasks simultaneously.

Similarly, when you use WiFi, it's no good asking "how fast is the signal modulated?" because you can't use every modulated bit. You need to know how much data the signal can carry, and how much of that data is being used by other people. And amongst those "other people" are the programmers who designed the standard. To make Wireless Ethernet work, each packet of data has to be wrapped up in a lot of other control signals. So, how much data can it carry, exactly?

It varies!

Let's imagine you walk into a typical "hot spot" and log onto the WiFi network. You're sitting within about 10 metres of the access point, with a "good" signal. There are a dozen other people also sitting around at the coffee tables. You need to know "how fast will it run?"

First, let's examine the basics.

When you send a packet of data, it can be anywhere from 0 to 64 kilobits. That's the standard set by TCP/IP, and nobody is going to re-program the basic Internet protocol just for you, so you have to live with that.

Around that packet, you will have lots of control data, all stuffed into the Media Access Control Protocol Data Unit. And that MACPDU itself is stuffed into the PLCP (Physical Layer Convergence Protocol) block which has the entertaining name of a PPDU (PLCP Protocol Data Unit) - which sounds faintly obscene ...

Suppose you're typing into a terminal server, and each character you send goes instantly. It gets a PPDU packet for itself. Here come the bits:

First: 18 bytes of PLCP preamble

Next: 6 bytes of PLCP header

Then the MAC header of 30 bytes, the Logical Link Control (three bytes) and Subnet Access Protocol block (SNAP) of five bytes. Now, at last we can get around to the

TCP/IP Datagram which has an IP header of 20 bytes, a TCP header of 20 bytes, and finally

your data (one character, probably ten bits, but call it a byte)followed by

the last four-byte Frame Check Sequence.

Total PPDU: 107 bytes, of which your character is just one. So the absolute maximum speed you could possibly hope to reach, if you could type a new character every time the transport was ready to take a packet from you, would be not 11 megabits, but 100 kilobits per second.

Is that the actual payload? Hardly! It's both better and worse than that.

It's better, because most of the time you don't really care about how much throughput you get when you're typing. You only care about the latency; you want the character appearing on the display instantly, without a couple of seconds delay. A hundred kilobits is far, far faster than any keyboard can accept data.

But it's worse, too; because when you are actually transmitting data over Wireless Ethernet, you want BIG packets. Your PPDU can't be as big as a TCP/IP datagram: it gets chopped up into 2Kbyte chunks called "data frames" as defined by the IEEE 802.11 Ethernet standard. But those packets don't just travel as they do on a wired Ethernet connection.

The problem is simple. You don't just "transmit" a PPDU. There's a long and complex dance involved. To quote the excellent Norwegian academic and research network, UNINETT,

"Transmitting the data is not just burping out a bunch of signals on the air. A strict set of rules is governing the way a transmission should behave (CSMA/CA). First the sender has to wait a period of DIFS (Distributed Coordination Function InterFrame Space) time of 50 Usec before the channel is presumed clear of traffic. Then a Data Frame or a Request to Send frame can be sent. The receivers answer to this is with an ACK or Clear To Send, accordingly. The receiver has to wait a SIFS (Short InterFrame Space) time of 10 Usec before this reply is sent."

Here's their illustration of the sequence of sending a typical TCP/IP datagram:

The problem is the PLCP pre-amble. It was designed when the first 802.11b standard was released, and that ran at one megabit per second. The pre-amble, therefore, has to be compatible with all old 802.11b cards and so it MUST be transmitted at one megabit per second.

At one megabit, the preamble is a trivial, insignificant portion of the whole datagram. At 11 megabits, however, sending the long preamble takes exactly the same time - just about 200 microseconds - which is a very significant proportion of the datagram time. Roughly, including other preambles and "quiet time" it accounts for half the data that in theory could be carried.

The arithmetic could not be simpler. It means that the total throughput of all users attached to an 802.11b access point is never going to be more than 5 megabits per second. Similar calculations will reveal that 802.11g access points will have a maximum throughput of 22 megabits, not 54 megabits; and things go down hill from there. There's retries, collision avoidance, lost packets, and a host of other problems which can happen, not to mention that you may have to get your signal through a crowd of humans, all blocking it ...

Good news? Well, yes, there is good news, too.

At a public hot spot, it is almost certain that almost nobody is trying to shift huge volumes of data at maximum speed. Most Internet traffic occurs in bursts. When there are downloads, they're off the Web, and most people on the web have to pay for speed; you won't often find a site that tries to send data faster than 512 kilobits per second, and you'll find lots that don't even try to go that fast. So that leaves plenty of bandwidth at 5 megabits total; ten users all downloading flat out from each other will be able to keep that going (in theory) without horribly affecting the total speed of any of them, talking to the Web.

There's also the fact that most of you will be using the Web itself. Your hotspot, nine times out of ten, will be linked to the Internet at 512 kilobits, because that's cheap ADSL. The hot spot admin may have set up a clever local proxy to supply a large number of common pages, but if you're trying to get the latest service patch for Microsoft Office, the limitations of the WLAN will simply not figure in your life.

On the other hand, if two of you are trying to swap files using the hot spot network, and there are a dozen other people logged on, but sitting far enough away that they're running at a megabit instead of 11 megabits, then be patient, OK? Ethernet is a shared medium, and it is always slower than you think ...