[SCFN] [Fwd: [Fwd: Re: Long Range Throughput - Real World Experiences]]

[Michael Mee]

Some discussion on building > 1 mile links

-------- Original Message --------
Subject: Re: Long Range Throughput - Real World Experiences
Date: Mon, 10 Jan 2005 16:12:05 -1000
From: Jim Thompson <jim at netgate.com>
Reply-To: SeattleWireless Development List <dev at seattlewireless.net>
To: SeattleWireless Development List <dev at seattlewireless.net>
References: <00b301c4f771$c9709420$6700a8c0 at artell.net>
<41E32616.7020305 at seattlewireless.net>

Matt Westervelt wrote:
> The links at NodeDexter <http://seattlewireless.net/NodeDexter> have 
> been solid since December (Senao 2511 PCMCIA and MiniPCI)
> 
> Distance to MultiLocal: 0.8927 miles
> Distance to NodeOne: 1.0882
> 
> Dexter has 16db Vagi antennas. 
> <http://pacwireless.com/products/vagi_series.shtml>
> 
> Standing on the roof at Dexter,  you can pick up multilocal with a 
> laptop and no external antenna, but adding antennas gives you a lot more 
> room. :)
> 
> <http://stats.seattlewireless.net/dexter/net4521/>
> 
> -matt

Matt (and Andrew),

The prism2/2.5/3.0 chipset firmware has no ability which I (or, frankly,
Jouni) know of that will allow the ACK timeout or SIFS interval to be
set from its IEEE-mandated setting.  (9usec for 802.11g/802.11a, 20usec
for 802.11b).   SIFS is typically set to 1/2 the slot time, for reasons
I won't go into here.   So for 802.11b, SIFS is 10usec, and for 802.11g,
its between 4 and 5.

In 802.11, packets are retransmitted from the MAC layer if an ACK is not
received within a SIFS duration. The transmitting node (the firmware on
the card if you're running Agere or Prism cards), assumes a collision
has occurred.  The transmitting node also goes into exponential fall back.

Since light (and radio) waves propagate around 300m/usec, and the packet
has to get "there and back again", plus the time needed to actually xmit
the packet,

If radio can propagate 300m in 1usec, then it can travel 3000m in
10usec, since we have to go "there and back again", the maximum distance
you can travel and not violate the SIFS boundary is 1500m.   In reality,
this is a little less, because the packet has to be serialized at the
receiver before it can checksum the packet and generate an ACK. 'c'
isn't quite 300m/usec, either.

Still, 1500m, max.  Interestingly, there are 1609 meters per mile.

Yes, many longer links are known to "work", but all of these, by
definition, must either have lax timers for receiving these ACKs, or
these links are actually receiving the ACK after transmitting the second
packet (and here both the time lost and the random backoff are cutting
into "available bandwidth", to say nothing of the chances that the 2nd
(or 3rd) packets get stomped because the transmit side decides to resend
just before the ACK would have been received, smashing the ACK.  (No
full-duplex radios, natch.)

There is a third possibility, EDCF (implemented in 802.11e or WME).
Here we can do a bit better job of "scheduling" when any given node
sends, so we won't end up in a random wait period (as much), can't
exceed the speed limit, however.

There is a fourth possibility, of course.  We could throw CSMA/CA and
its ACKs away and "invent" some "slotted Aloha" protocol.  Its been
done, and there are issues, but it is a possibility, just not on
Intersil or Lucent cards.

No amount of antenna gain or transmit power (or interference avoidance)
is going to increase the propagation velocity of an 802.11 packet
through the atmosphere.  If you do find a way to make this happen,
please let me know.  I'll pay for the patents (if I'm convinced that
you're right), and we'll all be rich.

If you're Atheros-friendly, then madwifi comes with a separate program
named 'athctl' that allows one to set the slot time.  The meat of the
solution looks like:

          int slottime = 9+(distance/300)+((distance%300)?1:0);
          int acktimeout = slottime*2+3;
          int ctstimeout = slottime*2+3;

          printf("Setting distance on interface %s to %i meters\n",
		device, distance);
          setsysctrl(device, "slottime", slottime);
          setsysctrl(device, "acktimeout", acktimeout);
          setsysctrl(device, "ctstimeout", ctstimeout);

Cisco has also changed the ACK timing in their 802.11b-based "bridge"
products.

As for you links, 1.0882 miles is 1751 meters, or 5.83 usec, which is
right on the hairy edge of having a problem.  Likely there is some
'slop' in the firmware, and you're getting away with it.  (I looked
once, when Vivato had firmware source, but I can't recall the exact
number, nor could I reveal same.)  The shorter link, at 1436m, is
'in-bounds'.

Jim
_______________________________________________
Dev mailing list
Dev at seattlewireless.net
http://seattlewireless.net/mailman/listinfo/dev