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.
