[CUWiN-Dev] Long-Range Links: acktimeout and ctstimeout on Atheros

[John Atkinson]

David,

As you mentioned, the acktimeout and ctstimeout parameters with longer
distance 802.11b links appear to need some adjusting.  I have found a few
resources on the web that have clarified things somewhat, but nothing very
official.  In general WiFi cards are shipped assuming shorter distances,
what 802.11b was designed for; the Atheros chipset in our D-Link DLG520 is
specified, in the manual on their website:

Indoors: Up to 328 feet (100 meters)
Outdoors: Up to 1,312 feet (400 meters)

The default setting for both the acktimeout and the ctstimeout are 48usec,
they max out at 744usec:

DEFAULTS on Atheros

# sysctl hw.ath0
hw.ath0.smoothing_rate = 95
hw.ath0.sample_rate = 10
hw.ath0.countrycode = 208
hw.ath0.regdomain = 32976
hw.ath0.debug = 0
hw.ath0.slottime = 20
hw.ath0.acktimeout = 48
hw.ath0.ctstimeout = 48
hw.ath0.softled = 0
hw.ath0.ledpin = 0
hw.ath0.ledon = 0
hw.ath0.ledidle = 270
hw.ath0.txantenna = 1
hw.ath0.rxantenna = 2
hw.ath0.diversity = 1
hw.ath0.txintrperiod = 5
hw.ath0.diag = 0
hw.ath0.tpscale = 0
hw.ath0.tpc = 0


48 usec is enough time for light (~300m/usec) to travel 14.4km.  But the
radio wave must travel from point A to point B and then back to point A in
order for the acknowledgement packet to be received, so 48usec is suitable
for a point-to-point link of about 7km.  There would also be some additional
delay from the processing of the packet, at both points.

So I'm not quite sure why the default time is so high.  I can't imagine the
manufacturers designing it for a 7km link by default.  Maybe it has
something to do with the fact that the hardware is setup for both 802.11band
802.11g.  It could be that the parameter is not directly in usec (but the
general consensus on a google inquiry says that it is).  Another possibility
is that 48usec is not the default, and that it is dynamically calculated on
the firmware, but I've only seen it at 48usec, so that's unlikely.

In the Akwapim Community Wireless Network the longest link is 30km.  This
would require 203usec for both acktimeout and ctstimeout.  To calculate
timeout from the link's distance I am using this formula:

timeout = (((distance in meters)*2)/(300m/usec))+3usec

The 3usec is to give a safety margin for the processing delay.  I'm not
exactly sure how to calculate the processing delay; this appears to be what
MadWiFi's 'athctl' program is assuming.

------------------------------------------------------------

Changing my longest link nodes to this new value seems to significantly
improve both my packet loss and my round-trip packet times:

# ping -s 1024 10.0.249.80
PING 10.0.249.80 (10.0.249.80): 1024 data bytes
1032 bytes from 10.0.249.80: icmp_seq=0 ttl=255 time=96.587 ms
 ...
1032 bytes from 10.0.249.80: icmp_seq=99 ttl=255 time=96.926 ms
^C
----10.0.249.80 PING Statistics----
100 packets transmitted, 58 packets received, 42.0% packet loss
round-trip min/avg/max/stddev = 26.698/87.117/230.151/38.130 ms


# sysctl -w hw.ath0.acktimeout=203
hw.ath0.acktimeout: 48 -> 203
# sysctl -w hw.ath0.ctstimeout=203
hw.ath0.ctstimeout: 48 -> 203
# ssh 10.0.249.80
root at 10.0.249.80's password:
Last login: Mon Jan 30 05:02:47 2006 from 10.0.60.154
NetBSD 3.99.11 (cuw_pc) #3: Tue Nov 29 02:10:12 CST 2005

Welcome to NetBSD!

CUWIN release 0.5.9+ Unofficial, built:20051129 rev:3658
Terminal type is xterm.
We recommend creating a non-root account and using su(1) for root access.
# sysctl -w hw.ath0.acktimeout=203
hw.ath0.acktimeout: 48 -> 203
# sysctl -w hw.ath0.ctstimeout=203
hw.ath0.ctstimeout: 48 -> 203
# exit
Connection to 10.0.249.80 closed.

# ping -s 1024 10.0.249.80
PING 10.0.249.80 (10.0.249.80): 1024 data bytes
1032 bytes from 10.0.249.80: icmp_seq=0 ttl=255 time=117.322 ms
 ...
1032 bytes from 10.0.249.80: icmp_seq=100 ttl=255 time=37.612 ms
^C
----10.0.249.80 PING Statistics----
101 packets transmitted, 84 packets received, 16.8% packet loss
round-trip min/avg/max/stddev = 18.563/62.968/125.982/27.478 ms
#

---------------------------------------------------------------


The following pages seem generally compliant with what we are experiencing:

http://nuke.freenet-antennas.com/modules.php?name=News&file=article&sid=22
http://socalfreenet.org/pipermail/discuss_socalfreenet.org/2005-January/000010.html
http://www.mikrotik.com/Documentation/manual_2.7/Interface/Wireless.html



Regards,

John Atkinson
Wireless Ghana @ http://www.wirelessghana.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.chambana.net/mailman/archive/cu-wireless-dev/attachments/20060130/de6c3860/attachment.html