Slashdot Mirror
The Joys of Microwaves And Wireless
Simone Paddock pointed me to the article on O'Reillynet about some quick and dirty testing of WEP, wireless, microwaves, ovens and all sorts of fun stuff. The article is entertaining and informative - my favorite kind.
Obviously, this man has no fucking clue about the technology he is reviewing. Does he realize how Direct Sequence Spread Spectrum works? Does he realize that ANY DSSS 11Mb link will result in an absolutel MAXIMUM throughput of 4-5Mbps because of the radio overhead (30%) and the asyncronous nature of radio communication? Does he know the frequency and spread of the channel he is on? Does he know that that particular DSSS channel probably doesn't overlap with the frequency of his microwave oven, since, if it did, he would have probably seen somewhere in the range of a 30-80% drop in bandwidth? Microwave ovens appear as almost a tall vertical line usually centered at 2450MHz with a maximum of +/- 1MHz spread on a Frequency/Power graph, while DSSS radios have a spread of almost 7MHz. Does he know how WEP operates? Does he understand that WEP adds absolutely zero overhead to the actual radio data because it boils down to a SIMPLE KEYPAIR HASH THAT IS DONE IN HARDWARE? Does he realize that if he got a "2.4 GHz" cordless phone that operated with a frequency hopping radio as most of them are that he'd get almost 50% data rate reduction despite his phone working wonderfully? Does anyone seem to understand that DSSS sucks and is only marketed above FHSS because it is CHEAPER?
Fucking stupid idiots buying 802.11b DSSS.
"Before we get to the numbers, I'd like to point out that even with the above fancy command, there was still a small amount of system overhead in actually getting the packets sent. As the exact amount is difficult to calculate but non-trivial, I decided to weigh the figures like this:
At 1 Mbps, it should take 11.00 seconds to transmit my 11 Mbit file, in the best possible case. On average (each test was sampled five times and averaged), it took 14.91 seconds to complete.
So, we have 3.91 seconds of unaccounted-for overhead (or 35 percent of the total transmission time.) For purposes of argument, we'll assume that the 1 Mbit speed is optimal, and deduct 35 percent from all transmission speeds (chalking it up to system overhead.) And so we are grading on a curve.
I may be crazy here, but why does the amount of non-transmission overhead vary indirectly with the speed of transmission? He mentions early in the article that there is a small amount of overhead in generating the bytes he's sending and timing the process, etc. because of CPU time and accessing the hard disk. Why then does he scale the overhead percentage-wise with each of his tests? That overhead time shouldn't disappear just because you're using a faster connection, it should stay exactly the same - the rest of the time should vary with the transmission speed. If you redo his calculations without scaling the overhead, the results look a lot more logical for the bandwidths he's using (bandwith and transfer time vary more correctly with each other, that is).
--Brogdon
This tagline is umop apisdn.
If one's to perform such a silly test (see earlier post about FCC regs and devices that need to be able to deal with EM interference) then at least test it with something more than a cupwarmer.
---
This essentially means "Take these 11 million random bits, copy them over the network using no encryption, just dump them into the bit bucket on the other end, and tell me how long it took you." I did this to try to minimize the impact of disk usage and CPU crunching, and just try to make the bits fly as fast as possible.
Umm... well, if he used ssh in order to make a connection to his other computer, wouldn't he still be technically using encryption? Or is the algorithm used to encrypt WEP connections really that much more taxing on the CPU?
Friends don't let friends use multiple inheritance.
I admit that 104-bit encryption is as hard to break as 128-bit encryption now, but Lucent is exaggerating the card's cryptographic strength by a factor of 2**16=65536. Not good!
As an engineer who works on 802.11 radios, I have a few issues with these tests.
First, the author performed only one test for each configuration. You can never come to a valid conclusion about performance from a one-shot test.
Second, the author doesn't really know much about RF, otherwise they'd realize that Microwaves are shielded to prevent from cooking the person operating the thing. While the shielding doesn't stop everything, it stops enough to let most 802.11 traffic get through without too much difficulty. As others have pointed out, the way to go is to operate other devices that communicate at 2.4GHz, such as certain cordless phones, Bluetooth devices, etc.
Third, the author doesn't appear to have read much on 802.11, or the author would realize that some amount of the overhead involved in 802.11 is used up in wireless headers that a simple application is never going to know exist.
Fourth, the author used tests on one vendor's radio to come to a conclusion about all 802.11 radios, and I can tell you that not all radios are created equally.
On the other hand, the author's results aren't actually terribly off from the performance seen in most 802.11b radios. Most 802.11b radios actually get a final throughput of about 3-5Mbps when running at "11 Mbps." Some of this is due to bus speed limitations (PCMCIA is slow), and some of it is due to the radios themselves (hey, you try getting a nice fast processor in there and maintain the price points), but whatever the limitation, no radio gets much more than 5Mbps in the best-case scenario (at least, of the radios currently on the market).
In the meantime, I'm looking forward to 802.11a, which will operate in the 5GHz band (hopefully, there will be less interference there) and should have a throughput of about 54Mbps (if they can ever finalize a standard, that is).
But I keep getting these festering lesions on my arms and chest when I try play EQ or Q3A. Must be 'line noise'.
"I pray that I never suffer an internal burn" - Nicolai Tesla
The next Slashdot story will be ready soon, but subscribers can beat the rush and slashdot the links early!