Very nice explanation! Thanks!
On 12/2/05, Jim Thompson <[EMAIL PROTECTED]> wrote: > the overheads aren't limited to beaconing and CSMA/CA. The largest > 'overhead' is that the 802.11 MAC can't keep the air "full". There are > delays due to turn around (for ACKs), overheads due to the preamble and > headers, etc. 802.11g has a further requirement for "protecting" > existing 802.11b clients by sending a CTS frame prior to sending the > data frame (though this can be disabled. > > In theory (and I strees *theory*) the performance of 802.11's PHYs over > TCP, with 1500 byte frames (802.11 allows larger frame sizes, but > Ethernet does not) expressed in terms of maximum thoughput for a single > pair of stations (or a STA and an AP, if you prefer) looks like this: > > 802.11b: 5.6Mbps > 802.11a 27.3Mbps > 802.11g (no protection frames) 27.3 Mbps > 802.11g (with CTS protection frames) 13.0Mbps > > And, you'll find that as you add users to an AP, the throughput does not > fall-off linearly with each new associated station. > > In theory the 'turbo' modes can get you 2X this, but sending twice the > signal through the PA means that not only does tx power get pulled back, > but the rx sensitivity drops, and the likelyhood of an error sufficient > to destroy the modulation envelope goes up as well. You will find that > you can't get as many frames through (undamaged) running 'turbo' as you > can with the same "standard" modulation rate. > > 802.11e offers an alternative MAC which can eliminate some of the 'dead > spaces' in 802.11's standard DCF MAC. This can increase performance > quite a bit. (And, in keeping this "on" the subject of pfSense, pfSense > should be able to support this newer MAC, though I need to go see if > there is a way to enable it.) > > The Atheros chipsets also support compression of the datastream, and > something called "fast frames" where the intra-frame protocol is changed > to reduce overheads as well. > > If you put it all together, and have near-perfect conditions, (and the > moon is in the correct phase) a pair of Atheros cards can stream data > (say, a ton of zeros) back and forth around 90Mbps using TCP. Cut the > compression out and this falls to around 65Mbps. Cut turbo and this > falls to around 33Mbps. See above for throughputs without frame > bursting and "fast frames". > > Of course, at short range required to actually see 90Mbps, you might as > well use an Ethernet cable. > > The real news here is that, with a bit of work (say to add the 4-address > frame support that madwifi currently enjoys) pfSense should be able to > 'bridge' across wireless with 30Mbps or more at reasonable distances. > This is a marked improvement over the current situation. > > jim > > Nelson Papel wrote: > > >Well, even with high end 54Mbit equipment (Cisco AP's and cards) in an ideal > >environment you won't get much over 22Mbit, so doubled for 108Mbit is > >effectively 44Mbit max throughput. Wireless Ethernet has a LOT over > >overhead data for beaconing, collision avoidance, etc, etc. The wireless > >data rates reflect the raw bits that are being transferred, not just the > >data. > > > >Nelson Papel > > > >-----Original Message----- > >From: Marc A. Volovic [mailto:[EMAIL PROTECTED] > >Sent: Friday, December 02, 2005 5:21 > >To: [email protected] > >Subject: Re: [pfSense-discussion] WRAP and WAP > > > >Quoth Holger Bauer: > > > > > > > >>Works great. I have several of these in use. However you won't get 108 > >> > >> > > > >You almost never get 108Mbit with anything, in my experience. Rarely can > >one obtain something approaching 40Mbit... > > > >But the WRAP itself works great. > > > > > > > > > >
