on nbd's site there is a dctrl program that greatly improves long distance datarates here. (from 2 Mbps to 48 Mbps on 9 km link). Where could I find the source code ? (would like to integrate it into wificonf.c)

tnx

I think you can open a ticket for this request and nbd will probably take it

If it really works, then I will integrate it into wificonf before rc5...

Well, it really works (quite welcome to come and have a look here in S. Portugal)

One system (7 km) has an OpenWrt wrt54g v2.2 (inf mode) and and old wap54g v1 access point with Linksys firmware, also communicating with near-by clients. The datarate gets to 48-54 Mbps but today I had to repeat the dctrl command a few times. Then the rate goes to 48-54 right away from the 2 Mbps it falls back to after some time. Have no access to the wap54g OS so it's a bit difficult to analyze only seeing one side.

A recent system has two wrt54g v 3.1 and OpenWrt on both ends (9 km), doing exclusively that. Distribution to local clients is done with a third OpenWrt  router. The long-haul is stable now for almost a day and the datarate fluctuates with weather conditions (it is a bit rainy today) between 36 and 54 Mbps ! No external amplifiers, just two fairly big 80 cm parabolas on either end with homemade 50 ohm feeds and the full 250 mW setting.

Thanks NBD !!! for what to us is a big breakthrough as it enables passing multiple adsl links through one radio channel.

The insight of today, issues with hidden node and ack/rts timing, made me choose the different topology for the second system, separating the one long-haul, and the myriad of short distance links.

For addition to RC5 would suggest to differentiate between yes/no ap, i.e. yes/no multiple connections. If the communication is just bi-lateral one distance parameter wl0_dist suffices. In case of an ap it would seem logical to have a list of [mac address <> distance] pairs so that the ap can differentiate between the clients in how long to wait for acknowledgement.

Please let me know if I can help testing the dctrl routines; by the way, where can the dctrl source be found ? Would be fun to experiment with it.

rgds
doddel

(Last edited by doddel on 17 Feb 2006, 23:15)

Have in the mean time experimented further and discovered a typo in one of my scripts that did set wlo_dist i.s.o. wl0_dist, which is the variable I use in some scripts as '/etc/dctrl $(nvram get wl0_dist)'.
Now both long distance links work stable at high datarates in the 36 - 54 Mbps. S/N is about 18 dB and have  acceleration features active (frameburst, shortslot).

Some reference material: http://www.compex.com.sg/home/whitepaper/LongRange.pdf

(Last edited by doddel on 19 Feb 2006, 16:47)

I have integrated the distance control stuff into the wificonf source. See https://dev.openwrt.org/changeset/3275 for more information.

thanks for the inclusion of this feature felix.
Two observations:
1) the extra slot time is calculated as the one-way time the signal travels in microseconds. But we have observed, and it is logical, that one has to calculate with twice that, i.e
val = 9+(val/150)+((val%150)?1:0);
since the acknowledgement of reception has to come back as well.
2) is it your intention that WLC_UP, as part of the start_bcom routine, does not get called anymore ? With the distance setting only WLC_W_REG and WLC_SETSHM get called; without distance nothing.

Will experiment a bit further with the shm and reg settings and this undocumented 510 offset.

Thanks for the info. Both is fixed in current svn.

I wonder why it's calculated that way, though. I pulled the calculation from athctrl in the madwifi sources ...

Well, i thought it might be like this:
9 microseconds is the 'short slot' time. Electromagnetic waves travel at about 3.10^8 [m.s^-1].
So by dividing the meters by 300 you get the time it takes to travel the meters in microseconds.
As double the distance is more relevant to the acknowledgement reception i have suggested 150.
This time is added to the 9 microseconds and rounded to the next microsecond.
Have no idea what this 510 value is about.

I have reported in the general thread on this matter that i found that all gmode protection needs to be switched off, which is possible in a long distance dedicated link that does not need to support 802.11b stations.
A good explanation of the effective throughput possibilities i found in
http://www.oreillynet.com/lpt/a/4085
Over almost 9 km it now operates at 8 Mbps effectively, with 'wl rate' reporting 36 - 48 Mbps !

(Last edited by doddel on 28 Feb 2006, 10:14)

Some peculiarities observed:
when new wifi with distance setting gets called and returns
1) as AP the distance setting will be there and remains
2) as INF client the standard short slot setting will be there; apparently the register tweak comes too soon and gets overruled by broadcom's driver. Doing the dctrl later manually does work, even a manual wifi ; dctrl sequence works, so it must be a matter of very little time.
Have put the register setting as the very last thing that wifi does but that did not resolve the problem.

On the side, but not important:
With a longer slottime set, 'wl shortslot' will report 'short', regardless of nvram settings and wifi action with those.

Studied this with a little utility program that shows the registers; that is to say the reg setting works, the shm i did not get to report properly by inverting the write actions.
http://www.dorpstraat.com/OpenWrt/sdist           (the binary)
http://www.dorpstraat.com/OpenWrt/showdist.c  (the source)

Please try this patch: http://openwrt.inf.fh-brs.de/~nbd/wificonf.patch

applied the patch, compiled it, and tested it on a station in infra mode that associates with same software on other side in ap infra mode. No improvement observed I am afraid. Upon exit of wifi the slot time has been  overwritten to $207 (%d 510 + 9). I can then apply dctrl 17000 and the slottime will be and remain $240 (510 + 9 + 17000/300). I am not using wds by the way as your patch involves the wds watchdog.

It's not a big problem as far as I am concerned. Wifi gets called not too often and I have adapted S40network and a few of my own monitoring scripts to have dctrl follow the wifi command. Am really very happy and well served with your experiment to combine the incomplete bits of information about these registers and have a go at it !
So my suggestion would be to add dctrl to the wificonf package, it only doing something when wl0_distance has been set. Add execution of dctrl to scripts that launch wifi like in /etc/init.d/S40network. The interaction with watchdog actions i cannot test as the long range system is live here and i am not using wds.

Unrelated:
As I was using my own wificonf with distance addition i had to change a few nvram variables to get your current wifi to work and do the test. As I am using WEP (i know it is insecure) i came across a nvram parameter that is used by wificonf but is not documented (anymore) in OpenWrt's nvram documentation being wl0_auth.

(Last edited by doddel on 28 Feb 2006, 23:33)

I have updated the wificonf.patch file and it should work now.

Have done the test after eliminating a few glitches in the code and indeed this time it works ! After running wifi initially the setting is wrong but within a second it gets then set properly.  Thank you !
The corrected patch:
http://www.dorpstraat.com/OpenWrt/wific … dist.patch

Is it the intention that wds gets activated always when not in ap mode, without the option to disable it  ?

{The corrected glitches:
wificonf.c: In function `set_distance':
wificonf.c:227: error: `v' undeclared (first use in this function) 
wificonf.c: In function `start_bcom':
wificonf.c:246: error: `val' undeclared (first use in this function)
wificonf.c: In function `start_watchdog':
wificonf.c:296: warning: pointer type mismatch in conditional expression
wificonf.c:366: error: `ifame' undeclared (first use in this function)
}