Wireless networking [was Re: [NCLUG] Re: Sean's Social Hacking]

[John L. Bass]

> Date: Sun, 21 Jan 2001 16:06:14 -0700
> From: Sean Reifschneider <jafo at tummy.com>

> On Sun, Jan 21, 2001 at 03:32:35PM -0700, John L. Bass wrote:
> >	features like diversity antennas on the AP. The units are
> >	PRISM-II chipset, based on the reference design.

> I forgot to mention that the Addtron uses Prism-II as well.  The
> latest pcmcia-cs versions wvlan_cs driver will run the Prism-II as
> well.

One note: Addtron cards were, at one point, 3.3V only (may still be) - and
didn't work in everything (still a lot of 5V only PCMCIA slots).

> >data rates depend on packet size mixes, but are around 2-5mbps for
> >802.11b DSSS radios and FHSS 1-2 mbps radios have effective data rates
> >well under 700kbps (basically floppy speed). With either technology,

> Hmm, not based on what I've seen.  My WebGear cards max out on transfers
> at around 135KB/sec -- nearly double 700kbps.

The point was that at about the same cost, FHSS radios are a LOT slower.
Thanks for the hard current data to make that point.

8*135=1,080kbps which is about 54% above the short test I got at a trade
show running a quick test last year. As I noted earlier, with wireless
802.11b radios generally deliver better than 480KB/sec, or better than
355% faster than the 135KB/sec figure - nearly 4X faster.


> >collisions are costly, and significantly impair performance - the slower
> >the data rate, the higher the probability of collisions and the higher
> >the cost of a collision, as the number of stations increases.

> Except you'd think that a laptop talking to a desktop in AdHoc
> mode with a 50KB/sec transfer going on would have plenty of time
> to transfer interactive sessions, instead of having 5 to 10 seconds
> to wait for your keystrokes to show up.

> In most cases the WebGear works fine, but when you load it it sucks.

When you do the math at 2mbps (completely ignoring 802.11 overhead and
ACK timing/delays) it takes a minimum of:

	1.500 Kbytes/packet * 8 bits/byte / 2000kbits/sec = 6 ms/pkt

Due to the 802.11 protocol (1mbps rate for headers/acks and RTT for data/ack
packet pairs), it can take a little over 50% more time (depending upon host
driver and hardware design timings or about 9ms/pkt).  Expected performance
for the technology is about 80% of 1/(.006*1.5)*1.5 = 133KBytes/sec. Your
figure of 135KBytes/sec is right on the mark for what would be expected from
one station to another on an otherwise idle 2mbps wireless network.

Add a second data stream in the reverse direction, or a 3rd stations traffic
to the mix, or RF interference - then three 802.11 protocol latencies kick in:

	1) ACK timeout period

	2) Exponential Random backoff

	3) Automatic retransmission.

Unlike wired ethernet, collisions are not detected during the 802.11 header
frame ... but rather a timeout occuring due to the lack of the expected
802.11 ACK packet (pkt xfer time + MaxRTT). When collisions or RF interference
are present, there is a sharp increase in avg pkt latency (3X or more) and
increases exponentially with the number of stations active. In fact, anything
that creates header CRC errors triggers these events/latencies.

The decrease from 135KB/sec to 50 KB/sec is not unexpected, the 5-10 seconds
interactive pkt delays is quite a bit worse than expected.

With reliable delivery on the wireless side, the FTP protocol is going to
open up it's window size (made worse by Linux large ftp windows) which coupled
with FCFS queue service implies interactive packets will be interlaced
behind a couple dozen ftp packets. With the thruput degraded to 50KB/sec
the effective pkt latency is about 33ms, and expected interactive latency
behind the ftp window size is about 700ms (or a little more).

Smells like something is very wrong with the WebGear driver/card, maybe lost
interrupts? Hardware Buffer overrun? Or a context switching glitch/spinloop/lockfailure.
The 802.11 protocol at 1-2mbps can do much better than that.

John Bass