RH 8.0 and hostap 10-12

[Peter Buelow]

> On zo, nov 24, 2002 at 10:28:43 -0600, Peter Buelow wrote:
>>   Interesting, but if that's true, I would think 5Mb/s would be too
>> high.
>> My experience with 10Mb/s ethernet, even with the best drivers and
>> lowest overhead equipment, is that you get a little above 9 Mb/s
>> actual transfer rate (TCP, not raw ethernet). I would assume that this
>> would/should be a little bit lower (is there extra overhead for
>> wireless? and I assume the driver isn't perfect yet). So, if it's half
>> duplex, then I would expect maybe 80% of that in ideal testing
>> conditions. I'm really seeing 90% according to netperf (assuming
>> 5.5Mb/s each way), so this makes me wonder a little bit. I'm not
>> questioning, but I would love to understand this all a little bit
>> better. Thanks for the info.
>
> One major difference with 10meg ethernet is that the return-traffic
> (acknowledgements and such; in TCP, everything is acknowledged with a
> reply packet) must be included in the same chunk of bandwidth.
> Whereas, with half-duplex systems like 802.11b, half of the bandwidth is
> allocated for each direction.  I'm sure there is a bit of overhead from
> the accesspoint beacons and such, but aren't there only 100 of those per
> second by default?  I'm not sure how large those beacon
> frames actually are, but I doubt they'd take up a significant chunk of
> the transmission time.
>
  Umm, ok, but the overhead of the protocol is only one part of the actual
overhead involved. There are interrupt and hardware latencies,
software/driver latency, and OS protocol overhead (the clear majority of
the overhead). Then, there is the wireless transmission overhead (missed
frames, retransmissions, and the like). And actually, I believe your
statement above is a bit misleading. Half-duplex means you only have
communication going one direction at a time (think stop lights) whereas
full duplex you can have traffic going both directions at the same time
(ethernet exists in both full and half duplex). It's not really
bandwidth divided in two. Also, TCP would be (for all practical
purposes) identical over ethernet or wireless or ATM or an E1 or
whatever so you really can't use that as an example here. Actually, TCP
latency makes up for a large chunk of the actual reduction in perceived
speed over a given link. TCP/IP is expensive when it all boils down
(with UDP being a little bit better, but not much).

> You say you assume the driver isn't perfect yet; software perfection is
> never an easy claim to make, but this driver is quite good, IMHO. I
> often experience a continuous 520KByte/s or better throughput with HTTP
> downloads.
>
> Mark

  hostap is actually very good. Better than my uncle's wireless AP in
terms of speed and has been very stable for my limited use (me, and the
girl two floors down who I think assumes there is a magical internet
connection to her powerbook). However, the driver is still in a state of
change and development. That was my point. Things are going to get
better, and things are going to break, and over time the driver will
evolve. That was my point with the imperfect comment. Anyway, I've never
gotten better than about 250KB/s over my DSL, so internet download
speeds aren't what I'm most interested in. I am more interested in
tinkering and tweaking and understanding the process better. Meandering
about the source is one way, and having suggestions about potential
improvements from this list is another.

-- 
"They that would give up essential liberty for temporary safety deserve
neither liberty nor safety." Benjamin Franklin
--
Peter Buelow
pete at putzin.net