OpenWrt Forum Archive

Topic: how to set 802.11 slot timings to improve long distance datarate

The content of this topic has been archived on 7 May 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Is there any documentation on influencing the timing of the broadcom radio ?
Issue: low datarate (1 Mbps) in spite of good signal strength and S/N ratio on long distance (8 km) link. Have found a description on the net that this is due to the propagation delay ( ~ 30 microsecond one-way) and the acknowledgements of reception not coming back within the timeslot that the radio is listening. Cisco's aironet bridge units have a 'distance' setting that just shifts the windows to compensate for this.
For the Atheros chips there exists the 'athctrl' tool to set ack+cts timeouts based on the distance between two stations.
Anybody on this forum that knows how to accomplish such a timeshift in the WRT54G Linksys units ?

(Last edited by doddel on 14 Feb 2006, 12:18)

Hi,

After the messages from you regarding my own post, I did some searching around and found a thread in another forum discussing the same problem: http://forum.bsr-clan.de/viewtopic.php?p=10530. A procedure to improve the performance on long distance links using the wl utility was proposed in a post, and additionally, a utility which automagically sets some parameters, I do not know which, based on the distance:

I have been doing some experiments with the TX ACK timing, and I've come up with a small utility that changes a few parameters on the wireless chipset, which are *not* exported through wl.
The URL is http://openwrt.inf.fh-brs.de/~nbd/dctrl.
Syntax is: ./dctrl <max. distance in meters>
It probably only works on OpenWrt, but it might work on DD-WRT as well.

it works very well on my own asus wl-500g, increasing the transmitted rate from 1.8 Mb per second to around 5 Mb per second, and also increasing the rate in the other direction by a couple of hundred kilobytes per second from 4 Mb per second.

Hope this helps.

Hi Kolaf,

thanks very much ! Will follow up on this and compliments for your searching skills !

rgds

Wow ! This does the trick. Am getting 11 Mbps now, the max of ad-hoc mode over 9 km !!
The indication of distance in meters seems to be off by a factor of two though. Only after setting the distance 'going plus return' in meters I get the big jump in performance.

After switching back to inf / ap setting (imode bss) i get speeds of 48 and 54 Mbps reported on either side of the 9 km link. It's just incredible but true.

rgds

(Last edited by doddel on 17 Feb 2006, 01:25)

The distance thing is my experience too.  My link length is about 3 km, but I get optimal performance if I enter a value of 7000 m. However, it's a shame I cannot boast the same performance figures as you have even though my link is only a third of the length of yours.  On why link I get 4 to 5 Mb per second in each direction, and only with traffic in one direction.  If I tried a bidirectional test simultaneously I get about 4 Mb per second one direction and 600 kb per second in the other direction, totalling to about the one-way Simplex capacity.  My client reports an rssi of -10dBm, and the access point reports -60dBm rssi. I use 24 dBi directional antennas at both ends, and the 802.11b standard since this is the only one the client supports.

I tried setting the network to ad hoc mode by setting wl0_infra=0 in openWRT, and changing the corresponding settings in the client, but that did not affect my link capacity in any way.

(Last edited by kolaf on 17 Feb 2006, 10:36)

Hi Kolaf,

well,  there are of course other factors like standing wave ratio (SWR) that can have a negative effect through reflections in the coaxial cable. Because I have been struggling for so long with this issue, all RF factors here are really optimal (i am a radio amateur also).
S/N here is appr. 20 dB with 80 cm parabolic antennas with homemade feeds on either side of the 9 km and 250 mW txpwr.
Also noted that any script that gets invoked that calls 'wifi' (e.g. /etc/init.d/S40network  in the 'wifi up' line) will finish dctrl because wifi resets the radio. So make sure the dctrl is called after any place where wifi features.
I wrote a few more scripts that monitor the link and also use wifi and I adapted those in the mean time.

Success !

Fancy that, I am a ham as well smile.  But I don't really have the equipment necessary to measure SWR at 2.4 GHz, and I do not have very much information about the antenna feed cables that I use, except that they are "low loss" wink.  The only real information had to go on is therefore the reported rssi at both ends, and the inferred link quality.  That doesn't tell me much about SNR and such.How did you get your SNR? did you calculated from actual measurements, or it is based on transmitter power, feed loss, propagation loss, antenna gain and so forth? And while on the subject, how were you able to set the transmitter power to 250 mW? On my wl-500gx the highest transmitter power I can set is 19dBm=79mW, anything above that is just ignored even if I attempts to set  the override option.  I don't know that increasing the transmitter power at that end would gain anything, though, says the received signal strength at the other end is already pretty good.

Do have/know of any good methods/tools to monitor link quality?

the antenna feeds are of the disc pad type and the dimensions stem from a simulation package.
for feed: http://f1afz.free.fr/ao40-english/parab … patch_2.4/
for calculator: patch16.exe (ms dos program). But it's a bit off topic here. Use here 56,5 x 56,4 pad at 4 mm distance from 150 mm diameter round pad with N connector at 17 mm from small pad side (so off center). From top or bottom side for V polarization, from left or right side for H polarization.

The S/N is what the WRT54G reports under 'wl rssi' and 'wl noise' from a client and under
'wl rssi <mac address of client>' which mac you can get from 'wl assoclist', for an ap.

The power I set with the wl0_txpwr parameter; make sure the regulatory locale is ALL.
Or use 'wl txpwr1 -m 251' for the wrt54g; don't know the max. power of your boxes.

Would advocate that the distance setting would be a wl0_dist variable in OpenWrt that also gets sent to the radio chip by wifi(wificonf.c), with a 3000 default value when it has not been set.

So with a noise power of -35 dBm, and rssi of -57dBm  my effective SNR is approximately -22dB. This is definitely a very low number.  Two 24dBi grid antennas should be more than adequate to push a full signal over the 3 km. That gives me almost 50dB total antenna gain, and the "propagation loss" of 3 km at 2.4 GHz would be about roughly 109dB, giving a received power of ca. -40dBm (if I remember my link budgets correctly).  This is significantly more than what I actually receive, but in any case it would seem that the noise power has a significant impact on the receiver.

I guess I will have to try to shorten the cable of the antenna, and see what I can achieve with transmission power at the other end. I have yet to successfully increase the transmitter power of my ASUS beyond 19dBm.

Would you mind quoting me your rssi and noise figures so that I may have something to compare with?

rssi and noise here (2 x WRT54G v 3.1) give very different figures compared to yours. They are typically (averaging out fluctuations)
1) box in 'inf' client mode:
rssi -78 dB
noise -96 dB    i.e. S/N 18 dB, and reports rate values that fluctuate 36 - 54 Mbps

2) box in 'ap' mode
rssi -80 dB and reports 48 Mbps most of the time.
the 'wl noise' command doesn't work in ap mode, but S/N is probably also in the 16-18 dB range with high humidity in the path.

So agree with you that more Mbps should be possible considering your signals.

What are the steps u need to take to use this ? Can u just set it and the the settings change immediately or do u have to reboot ?

Just run the app, no reboot, must be run on every boot to work.

Thanks

Best results here with effective througput of data are obtained on the long distance 9 km link when operating
with
gmode_protection_control 1
gmode_protection_cts      1
gmode_protection_override 1
dctrl 17000

While 'wl rate' reports values between 36 and 54 Mbps, the realized rate when transferring a file using wget is appr. 5 Mbps. The waiting times are considerable during which no data get transferred when using 802.11 over these distances but at least there are no unnecessary retransmissions with these settings.
Enforcing gmode_protection_cts has a positive influence. When this is switched off the 'wl rate' drops to 2 Mbps, despite dctrl setting.

doddel wrote:

Best results here with effective througput of data are obtained on the long distance 9 km link when operating
with
gmode_protection_control 1
gmode_protection_cts      1
gmode_protection_override 1
dctrl 17000

While 'wl rate' reports values between 36 and 54 Mbps, the realized rate when transferring a file using wget is appr. 5 Mbps. The waiting times are considerable during which no data get transferred when using 802.11 over these distances but at least there are no unnecessary retransmissions with these settings.
Enforcing gmode_protection_cts has a positive influence. When this is switched off the 'wl rate' drops to 2 Mbps, despite dctrl setting.

What is your speed in KB/sec ?

If you say 5mbps is that like +- 550KB/sec ?

Yes, the Mbps are million bits per second. The link behaves about the same in both directions. Am using shortslot mode.
In longslot the troughput reduces quite a bit.
The 802.11 protocol was never designed for this long distance purpose. It would be more effective to send a number of packets, or bigger packets, and then wait for ackowledgement, like in AX.25, but in any case the link seems now more or less adapted to the 4 Mbps speed we here get from the adsl modem thansk to this dctrl radio register timing tweak. My initial thought that I now could send multiple adsl connections over one link proves too optimistic. Although the modulation of the radio channel could do much more, a lot of throughput capacity gets lost in idle waiting for 802.11 ackowledgement packets. The great effect of the timing adaptation is that the acknowledgements don't get lost anymore which before lead to the modulation being reduced to lower bitrate and the scarce throughput capacity being occupied with retransmissions.
Will continue experimenting to find the effect of the various settings.

(Last edited by doddel on 22 Feb 2006, 15:39)

Can't reach the dctrl scipt. Could someone post it?

Would like to correct my earlier statement about best gmode protection settings in long distance communication. Had not properly understood the effect on timing of these until i read this article and continued experimenting:
http://www.oreillynet.com/lpt/a/4085

Assumption is that the link is exclusively between an AP and a client in bss (infrastructure) mode (ap <> inf). I managed to get the effective datathrougput to 8 Mbps (wl rate reports 36 Mbps) now by switching G_PROTECTION, G_PROTECTION_CTL, and G_PROTECTION_CTS all off. Am doing the test as follows;
  the inf has httpd active and in //www is a symbolic link 'file' to //tmp/testfile which is some 6 MByte file.
  from the AP i do a wget http://<<ip of inf>>/file
  the file gets there in 5-6 seconds, i.e. 1 MByte per second effectively over the long-distance, using a distance setting of 17000 on both sides. When I set the distance to e.g. 14000 the required time increases from 6 seconds to 2.5 minutes !

When the AP also serves other clients and hidden nodes would exist these gmode protection settings are not advised because the AP should then give clearance to send to the various nodes. This will reduce throughput.
We have two long distance links, one exclusively long-distance, and one mixed.  Will add a second OpenWrt box to the mixed system and separate out the long-distance link from the local ones to get the same good performance there.

The discussion might have continued from here.