43

Using a wired connection, I get a 38 Mbit/s download speed. When I switch to wireless one (Linksys WRT54GL router with Tomato firmware), the speed drops to 23 Mbit/s even if the distance between the router and the computer is 2 or 3 meters.

Is that a maximum effective bit rate I can expect from an 802.11g connection?
Are there any settings I can tweak to to increase the download speed?

1
  • 3
    The overhead for WIFI links is significantly higher than wired links and the underlying mechanism is CSMA / CA, whereas wired is CSMA / CD.
    – dbasnett
    Jun 27, 2011 at 22:49

2 Answers 2

65

With strong signal, no noise, a client and AP that both do frame bursting, and a well-optimized app (actually a throughput test tool called IPerf) I've seen 802.11g TCP throughput of barely 30 megabits/sec.

In real world conditions I'm happy as long as it's over 15 megabits/sec.

The rule of thumb for 802.11 is that you can get TCP throughput of 50-60% of the signalling rate you're getting, and you only get the best signaling rate under the best conditions.

Update: Just realized I didn't answer some of your subordinate questions.

Is 23 megabits/sec the best you can do (assuming no frame bursting)? Yes as I recall, somewhere between 20 and 25 megabits/sec is about the best throughput you can expect out of 802.11g without frame bursting.

Are there things you can tweak to get better performance? Yes, here are some things you can tweak to get better performance. However, I'll warn you up front that some of them are probably more hassle than they're worth:

  1. Make sure you're on the cleanest channel available to you. The only way to do this reliably is to use a spectrum analyzer such as a Wi-Spy. Some people think they can get away with using something that only sees Wi-Fi networks like inSSIDer, but they're wrong. There can be a lot of noise in the 2.4GHz band that doesn't come from Wi-Fi gear, so inSSIDer would never see it, but a real Wi-Spy (or an even fancier spectrum analyzer) would.

    1b. If your gear is not just b/g but actually a/b/g, see if any of the 5GHz channels available to you are cleaner than any of the 2.4GHz channels, and if so, consider switching to 802.11a in 5GHz.

  2. If your equipment supports frame bursting but you haven't turned it on, you can turn it on. Different vendors may have different ways to described frame bursting, such as "turbo mode" or something. If I recall correctly, Broadcom branded frame bursting, plus some other tweaky proprietary performance optimizations, as "Afterburner". Beware that some of these things can cause interoperability problems, and tend to work best between chipsets from the same vendor, from the same era.

  3. If you have control over what tools/protocols you use to do your downloads, including the server side, then you can choose things that make more efficient use of TCP. For example, a good quality FTP or HTTP server is more likely to "keep the pipe filled" by constantly streaming the file using rolling buffers to make sure the sending-side TCP stack is never starved for data to send. In contrast, remote filesystem protocols like SMB and AFP tend to do individual reads and writes in blocks, so between blocks, TCP doesn't have anything to send. This can make a big difference over the course of a large download.

    3b. Again if you own both ends of the file transfer, you can look at TCP tuning. For example, make sure your client and server (especially the receiving end of the file transfer) is using an adequate TCP Window Size. TCP tuning is beyond the scope of this Answer, but if you Google for it and learn about things like bandwidth-delay products and optimum window sizes and delayed Ack and disabling Nagle's algorithm and using sysctl's (Unix / Linux / Mac OS X) and I guess registry editing (Windows) to adjust those things, you might find ways to squeeze a little extra performance out of your link.

    3c. Again if you own both endpoints of the file transfer, you could choose a high-performance UDP-based fast file transfer app. These apps are usually proprietary and require you to have the same app on both ends of the connection. Whereas TCP is very good at going as fast as it can without making Internet congestion worse, some of these UDP-based apps take the selfish approach of optimizing your file transfer speed without concern for the effect they have on network congestion.

Overall, if you've got a 40+ megabit/sec Internet connection, then 802.11g from 2003, which isn't any faster than 802.11a from 2002, isn't the right solution for you. Time to get some 802.11n equipment and party like it's 2007. Or some 3-spacial-stream 802.11n equipment and party like it's 2010.

3
  • Very thorough answer. Like any bandwidth or throughput or "how fast" question, the answer is nearly always "it depends". Jun 27, 2011 at 22:05
  • Thank you for an incredibly detailed answer! I would give it a few more upvotes if I could. And you're right - the tweaking is so much hassle that it's not worth it; it's time to get a new router. Jun 28, 2011 at 6:45
  • For example, 802.11g's raw data-rate is 54 Mbit/s, but half of that goes to half-duplex. Also additional preamble and already mentioned circumstances decrease the raw data-rate and resulted is ~23 Mbit/s.
    – Artfaith
    Nov 18, 2020 at 7:30
1

Testing on 802.11a has shown my best rates to be in the 20-22Mbits/sec range, using iPerf 2.0.5. Note that in my case, there's a VPN connection in the middle as well.

iPerf server:

iperf -s -w 128K

iPerf client:

iperf -c <serverIP> --tradeoff --len 8K -w 128K -P 1 -t 30 -i 5 -m
1
  • 1
    Be careful about manually setting the window size in iperf. Modern TCP stacks do TCP window auto-scaling unless you override it by specifying your own window size. And while 128KiB may have been plenty back in the 802.11a/g days, it's far too low for 802.11n and 802.11ac. If you want to manually set a TCP window size for 802.11ac, I recommend -w 2M (2MiB).
    – Spiff
    Aug 26, 2013 at 19:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .