RTS threshold, fragmentation, and other advanced WiFi settings

Question

Background: I'm in a noisy environment, and I'm trying to optimize my WiFi network to have a more stable connection for the somewhat high volume of users (~50-75 on a busy day). There are 4 APs, and I've already adjusted the channels and transmit power, and overall I have fairly decent coverage. However, I still get about ~10% packet drop when pinging Google and walking around the building, roaming from AP to AP.

In most WiFi APs I've seen, the default RTS Threshold is set at 2347 (from what I've read in various places, this setting counts as "disabled"), and Fragmentation Threshold is set at 2346. My particular brand of router is set at 2346 and 2346. I have several questions...

1. Where is the value of 2346 derived from? It seems somewhat arbitrary, however, the notes for Frag. Threshold indicates that it needs to be over 256 and an even number.

2. How are the RTS and Frag. Thresholds related? Their values can't be coincidence.

3. If modified, should they be changed together?

4. What's a safe value to try lowering them to, for starters?

My priority is not necessarily getting peak bandwidth for each device, but giving users a stable, consistent bandwidth/connection.

Answer 1

1. 2346 is the maximum 802.11 frame size. Setting the RTS and fragmentation thresholds to the maximum means that no packets will meet the threshold.

2. The fragmentation threshold limits the maximum frame size. This reduces the time required to transmit the frame, and therefore reduces the probability that it will be corrupted (at the cost of more data overhead). The RTS threshold specifies the frame size at which the transmitter must use the RTS/CTS protocol, which is largely to solve the hidden node problem. This obviously also adds overhead.

3. Not necessarily -- if you don't have a hidden node problem then changing the RTS threshold won't improve performance. In order for RTS/CTS to kick in the RTS threshold must be the same as or smaller than the fragmentation threshold though.

4. I would start with setting them such that a standard Ethernet frame is fragmented into two 802.11 frames (1500/2 = 750 bytes payload + 34 bytes overhead = 784 bytes) and any frames bigger than a third of a standard Ethernet frame uses RTS (534 bytes).

As far as I know though, both these settings only affect the transmitter, i.e. configuring them on the AP only makes the AP use them for its transmissions and doesn't make the clients use them for their transmissions.

Answer 2

That mixed b/g scenario is particularly suboptimal. You may want to review some of the previous discussions on the topic, such as:

Slowest wireless client dictates the connection quality of all others?

Also, another performance killer occurs when point A can receive point B's signal, but B cannot receive A's signal. Someone else on ServerFault pointed this out as the "hidden transmitter effect". More about that phenomena at the link below. They point out that:

"...While horizontal polarization is desired, the lack of inexpensive commercial horizontally polarized omni-directional antennas may require the use of vertically polarized antennas. A good omni- directional vertically polarized antenna will cost about the same as a parabolic antenna. Use of an omni-directional antenna helps minimize the "hidden transmitter" effect. "

http://www.arrl.org/using-ieee-802-11b-operating-under-part-97-of-the-fcc-rules

Answer 3

I disagree that "if you don't have a hidden node problem then changing the RTS threshold won't improve performance." Using CTR/RTS always lowers the chances of data collisions. Since every data collision causes data corruption and thus requires data to be re-sent, less collisions means less re-sending of data and less re-sending of data can largely improve your WiFi performance; of course only if there is a notable amount of collisions in your network.

To explain the details: A node always has to wait for a certain period of time and sense the channel for possible transmissions prior to stating an own one. Only if it doesn't sense any transmissions, it may start an own one. Without RTS/CTS, this transmission is directly a data transmission. If now two nodes both have the same idea and start a data transmission almost at the same time, then these transmissions will collide. The result is, that neither transmission makes it anywhere as all received data will be corrupted for all other node and the AP.

If RTS/CTS is used, the transmission starts with a RTS packet being sent by the node after the sensing. Only if that RTS request is answered by a CTS reply, a data transmission is started. Of course, if two nodes want to transmit at the same time, their RTS requests can also collide with the same negative effect that no RTS is received at all. The difference is, the entire network will recover much faster from a RTS collision than it will from a data collision. So a RTS collision is less harmful to the entire network performance than a data collision.

The downside is that RTS/CTS itself requires some network bandwidth on its own and it introduces new sensing times during that no other data transmissions or RTS/CTS transmissions may take place. To make things even worse, of course RTS/CTS always has to be performed using the slowest speed the network supports as otherwise nodes only supporting this speed won't see it. So basically you can say that RTS/CTS always lowers the theoretical throughput of your entire network, however if your network suffers by lots of collisions, either by the hidden node problem (which can also be caused by nodes from other networks just using the same channel as your network) or because your WiFi is crowded (as more nodes increase the chance for random collisions), it may in fact increase the actual throughput. Not the number of hidden nodes, the number of collisions is the important factor here, no matter how they are caused.

I read a study (I will update and add a link here once I was able to find it again), that suggests that unless your network is really small (less than maybe 6 nodes and covering only a small area) and not isolated from other networks using the same channel, using RTS/CTS almost always has a rather positive effect in practice. So why the threshold value? If sending the data would take as much time as a RTS/CTS handshake would take, there is little gain on using RTS/CTS, since whether the network has to recovery from a very small data collision or from a RTS collision won't make much difference. The better recovery from from RTS collisions is because RTS packets are very small whereas data packets are usually not. But for very small data packets, RTS/CTS just adds overhead for no practical gain.

And now you also know how a fragmentation threshold can improve network performance. On the one hand it limits the size of packets sent and as explained above, the smaller the packet in a collision, the faster the network will recover from it. And on the other hand, if there was a collision, only the fragment affected by it needs to be re-sent, not the entire packet. However, every fragment sent has an overhead of its own, so the more fragments being sent, the more overhead that will add and overhead is basically wasted bandwidth that could as well have been used for data transmissions instead.