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

[Quent]

The thing that counts is that I can sit at the dining room table and do
wireless Internet access via the DSL connected firewall that's in the
basement; I can roam about the house too. (as soon as I get some wireless
networking gear)

Most Internet sites have a lot more latency and less throughput than of
either DSSS or FHSS :-)

I appreciate all the data though! The timing is great; I just started
really researching this last week.

	Quent

On Sun, Jan 21, 2001 at 08:34:42PM -0700, John L. Bass wrote:
> > 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