Wi-Fi Performance

Those who have come from a fixed-LAN background may not expect some of the behaviour that a wireless-LAN exhibits, and hence may not be aware of some ways that they could tweak their Wi-Fi (802.11a/b/g) networks for better performance. This page discusses some of the performance issues with Wi-Fi and suggests some things that can be done to get extra speed out of your network.

I’ve put together a simple Excel spreadsheet to calculate theoretical Wi-Fi throughputs under a number of conditions. You may want to use it in conjunction with reading the notes below.

Hidden Nodes

One of the big differences between using a wire and using the air is that you cannot detect collisions. A device using Ethernet can detect when a packet it just sent has collided with another device’s packet, i.e. only one packet can be sent on the wire at any one time, and when two packets are sent at the same time (by different devices), it results in a scrambled packet. However, this detection isn’t possible on “Wireless Ethernet” or Wi-Fi.

One node (a Wi-Fi device) ‘A’ can be hidden from another node ‘B’, in the sense that it can’t hear its transmissions, but a third node ‘C’ can hear the transmissions from both. This may be due to ‘A’ and ‘B’ being out of range of each other, while ‘C’ is between them both and within range, or it may be due to something else. Anyway, ‘A’ and ‘B’ may both attempt to send a packet to ‘C’ at the same time on the same channel, resulting in ‘C’ receiving a scrambled packet (and not knowing which node sent it), while neither ‘A’ nor ‘B’ are able to tell that anything has gone wrong. As a result of this “hidden node problem”, Wi-Fi cannot use collision detection, it has to use collision avoidance.

The approach to collision avoidance that Wi-Fi uses is called DCF (Distributed Co-ordination Function), which is simply that a transmitting node negotiates to reserve the channel with the receiving node prior to sending its packet. This is done by exchanging small RTS (Request to Send) and CTS (Clear to Send) packets. There’s still a risk that a RTS or CTS packet from node ‘A’ could collide with one from node ‘B’ before either has reserved the channel, but as these packets are very small, there is much less chance of this happening than having big packets collide otherwise.

It’s almost always a good idea to use DCF, and most Wi-Fi access points will have it turned on without you having to do anything about it. Unfortunately, the down side is that it uses up a fair bit of the available bandwidth, particularly when the packets are small. For example, when sending large 1,500 byte IP packets on DCF-enabled Wi-Fi at an air-speed of 11Mbps, you’ll see a maximum speed of less than 60% of that. The rest of the bandwidth is taken up in signalling, including the RTS/CTS packets. Without DCF, the speed you’d see would be at most about 80% of the air-speed, so 20% of the 11Mbps bandwidth is used up by DCF.

So, if your access point supports turning off DCF, you may want to, assuming one of these cases holds: (i) you send/receive only small packets (such as VoIP packets), (ii) you are confident that all other nodes tuned to your Wi-Fi channel are very close, to avoid the hidden node problem, or (iii) you have only two Wi-Fi nodes and are sure that no neighbours or office-mates are tuned to your Wi-Fi channel.

Fair Scheduling

When multiple nodes wish to transmit on the same channel at the same time, the algorithms in DCF result in the nodes being scheduled to transmit in generally a random order. It also has the effect of making it likely that each node gets a turn to transmit before any particular node gets to transmit again. These sound like nice properties, and it is considered to be fair scheduling.

However, fair scheduling may cause some issues. Notably, the speed of the transmission and the size of the packet to be transmitted are not taken into account. So, where a slow node wants to send big packets, and the other nodes are fast, the slow node will dominate the time spent transmitting. This means the average speed experienced will approach the speed of the slow node.

A couple of the reasons you’d have a slow node on your Wi-Fi network is if it is a long way from the access point, or if there are walls between it and the access point. If you move, or turn off, such a node, you could see big speed increases from the other nodes on your Wi-Fi network.

Another reason is that you are sharing a channel with another Wi-Fi network, and although all your nodes are close to each other, one or more nodes from the other network could be running slowly. Shifting the channel used by your access point might move you away from it, and result in a speed increase.

Wired versus Wireless

There are two general ways to set up a Wi-Fi network, either as an Infrastructure network, or as an Ad-Hoc network. Most people use an Infrastructure network, which is one with an access point node, and these notes relate to this case.

All Wi-Fi transmissions from a node like a laptop or PC are intended to be received by an access point. These nodes also listen to transmissions where they are to be the recipient, and these will be sent to them from the access point. Where the ultimate desination of a packet is another machine on the same Wi-Fi network, the packet is first sent to the access point, then the access point sends it to the other machine.

Currently, access points run the Wi-Fi network on a single channel. So, a packet can’t be sent to the access point at the same time as the access point is sending the packet to another node. Sending the packet twice takes at least twice as long as sending it once, and so sending packets from a wireless machine to another wireless machine could be at least twice as slow as sending packets from a wireless machine to a wired machine, and visa versa.

Hence you shouldn’t run a server on a wireless network if you ever expect to access that server from the same wireless network. Access points almost always bridge their wireless network with a wired network, and performance should improve if the server is connected to that wired network instead.

This applies even in cases where you may not consider a machine to be a server. For example, where you are trying to share files between two wirelessly connected machines, or where you are trying to print to a wirelessly connected printer. Put the printer on the wired network, and perhaps use a dedicated shared directory that is on the wired network rather than sharing between wireless machines.

Also relevant here is my discussion on Wi-Fi performance with file transfers.