Slashdot Mirror
When 54 Mbps isn't 54 Mbps: 802.11g's Real Speed
eggboard writes "Matthew Gast, author of 802.11 Wireless Networks, filed this article for O'Reilly Networks explaining exactly how fast 802.11g really is: that is, what's the actual data payload and real throughput, not the rated maximum speed. His conclusion? In mixed 802.11b/g networks, which will be common for years to come, g is only 1.6 to 2.4 times faster than b, not 5 times faster as it is in its g-only mode. This article has real math based on the specs, rather than armchair speculation."
When you connect a 10bT NIC to a 100bT switch you get reduced throughput.
EVERY medium that I've seen specs for published the actual bit rate of the wire/cable/fiber, not the end user throughput. They can't know that because they don't know what protocols you will be running over the network.
Article X: The powers not delegated... by the Constitution...are reserved...to the people
Even the manufacturers make this point. From apple's site:
If a user with an AirPort-enabled computer or a Wi-Fi certified 802.11b product joins an AirPort Extreme wireless network, that user will get up to 11 Mbps and the AirPort Extreme users on the same wireless network will get less than 54 Mbps. To achieve maximum speed of 54 Mbps the wireless network may only have AirPort Extreme-enabled computers on it.
Its not like this was quite the surprise its being made out to be...
You're special forces then? That's great! I just love your olympics!
(Sorry for the parent post, I made a typo. Just s/802.11a/802.11b/ in the second bullet point. "oops" :)
Okay, I read the article, and here's a basic rundown (I think :):
So, to sum up the summary: If you start replacing your 802.11b access points with 802.11g access points, you'll see some performance gain with 802.11g client devices right away. When all your 802.11b client devices are gone (and thus all the 802.11b access points), it'll be way faster. Faster even than 802.11a.
Why is this billed as a bad thing? You get compatibility with your existing infrastructure, a little bonus performance now, and when the time comes, bang you get a big boost.
This is the kind of thing that sysadmins such as myself LOVE :)
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
Wireless networks have greater latencies than wired networks. Its just a fact. Windows NT (and various linux/bsd/other systems) is usually nice enough to automatically adjust the TCP recieve window size to your network latency. Sometimes it gets it right. Other times it gets it wrong.
For this to be a usefull test, you will need to at least publish what the window size was on each end. Also, making sure the immediate area was free of microwaves and blenders helps a bit.
Now, I fully believe that the test was accurate and that the speeds listed are a accurate representation of what an average 802.11g network will experience. But there are many things you can do to tweak your throughput much closer to the theoretical speed.
Karma: SELECT `karma` FROM `users` WHERE `userid`=138474;
Thanks to MADWIFI and this postI was able to get my Netgear WAG 511 working in a laptop in under five minutes. A walk in the park compared to the last time I configured wireless on my laptop.
I have not had a chance to thoroughly test it in a multi-signal environment, but the throughput is solid on B. There have been some drop-outs but I blame the D-Link access point to which I am connecting. (DWL-1000AP=junk, but at least it was inexpensive).
The WAG511 was on sale at Fry's for $80; I haven't seen it significantly cheaper on line, so I grabbed two.
This afternoon I am working on getting another card to work in a desktop with a pcmcia adapter to act as a host so I can unload the D-Link; then the higher-speed testing can begin. I have nothing but good things to say about the Netgear card so far. Thanks to all those who are doing the heavy lifting to make A/G support possible.
Why is this billed as a bad thing?
For those who understand how this works, it is not a bad thing. However the hardware is being marketed to the general public.
As a result you can expect that people who see the 5 x faster than b are going to completely skip the small text that disclaims this on the back of the box. I think everyone would be surprised if this did not include a significant number of ostensibly technically inclined writers who will report that they did not see the improvements advertised, and who will subsequently give the technology a bad rap.
One fix for this would be to make APs that ran dual modes, but on different channels. For example 'b' on channel 3 and 'g' on channel 9. The AP would have to be able to buffer traffic between the two channels, but it would have to do so if it were acting as a repeater in any case, which I believe it has to to operate in both b and g modes.
I do not know if this is likely to happen, or is part of the spec already. If it is, then people should expect to see a significant performance boost.
-Rusty
You never know...
But 802.11 isn't full duplex.
What everyone has to remember is it's not the transfer speeds that really matters IMHO. The additional available bandwith that is available is what the plus is for me. I had 14 computers on an 802.11b network and they crawled, now with a 802.11g AP, they cook, because they have more bandwidth to share. If they could come up with an AP that acts as a switch, now that would be cool!
Here are some real numbers.
Best Performance among various hardware
802.11g
wep off: 15.5Mbps
b card on network/wep off: 9.4Mbps
wep on: 10.3Mbps
802.11b
wep off: 4.8Mbps
Whenever the offence inspires less horror than the punishment, the rigour of penal law is obliged to give way...
This reduces the "TCP" he uses to a stop-and-wait protocol.
Unfortunately, I have no mod points, but I really wish I did so I could throw one your way.
Apparently, of all the supposed techies reading the article, only you caught that problem (hey, I'll admit it, even I glazed over on the details, so kudos to you). And that one change of his TCP simulation makes ALL the difference - If you take out all the part of a protocol that make it play well in a multiple-speed in-and-out environment, then yes, in fact, it will behave only slightly better than the worst speed in any direction. Almost a trivial statement, yet the parent post's entire premise rests on this one idea.
Sad. And again, kudos, good catch.
Unfortunately, many retailers no longer stock any 802.11a equipment, other than a couple of "universal" a/b/g cards.
I was in Best Buy and CompUSA and it is wall-2-wall 801.11g -- all "54 MBps!" in big, bold print.
It is a shame, since the 5 GHz band is so less crowded. I think "A" equipment is going to fade into a niche and be harder and harder to find.
Learning HOW to think is more important than learning WHAT to think.
when you hook up that 10baseT card, it slows down the rest of the hub to 10 baseT.
Not at all. An auto-sensing hub (does anyone still make these?) is actually a 10mbps segment bridged to a 100mbps segment. Each port connects to whichever segment it can talk to, and they're switched together internally. The whole thing does *not* drop to 10mbps when any 10mbps devices are present.
It would be nice if B and G played that nicely in the same spectrum, but they don't.
Indeed, what kind of dingbat throws out all that "sophisticated" stuff above the link layer and tries to estimate throughput using "real math"? The only way to get REAL numbers is by simply measuring the actual transfer. Not that it's impossible to model TCP's behavior mathemtically but jesus why bother for this?
Anyway on a slight tangent here... one thing that's interesting about TCP is that on very low latency media like an ethernet or 802.11 LAN, usually TCP actually performs *better* when you limit its window to as little as one or two segments. Otherwise it's just bumping up against the ceiling all the time and causing timeouts (doubling cwnd when you're already at the max usually loses enough packets that you don't get a fast retransmit). During initial startup of the connection the timeouts are quite long, which is why file transfers on a local LAN usually start out slow and don't get fast until they've been running for several seconds.