My situation -- two identical Buffalo WHR-G54S units. One acts as AP and the other as client Both are running Whiterussian 0.9. Units located about 1 km apart (gps data says 986 meters), with identical, huge, 90cm parabolic antennas at both sites. BiQuads, built based on Trevor Marshall's instructions as feeders, connected with less than 1m of RG58. LOS and a clear Fresnel zone. Running on channel 2. No encryption. No WDS. Both units have

wl0_distance=2000
wl0_txpwr=60
wl0_gmode=6 [802.11g (afterburner)]
wl_gmode_protection=off
wl0_gmode_protection=1

and

Fragmentation Threshold (default 2346) 2346
RTS Threshold (default 2347)                2347
DTIM Period (default 1)                        1
Beacon Period (default 100)                  100
Max Associated Clients (default 128)      128
Wireless Distance                                 2000

that is - all at default values.
Tests w/ Chariot, both units in the same room, default tx power and stock antennas clock at ~24mbits/sec, but when deployed as described above I get at most 8-9 mbits/sec throughput. NetStumbler on the client side, w/ a dlink dwl-650+ card, and the same big parabolic antenna shows a RSSI of 80 ! and the console shows this

root@buffalo12:~# iwconfig eth1
eth1      IEEE 802.11-DS  ESSID:"01"
          Mode:Managed  Frequency:2.417 GHz  Access Point: 00:16:01:XX:XX:XX
          Tx-Power:15 dBm
          RTS thr=2347 B   Fragment thr=2346 B
          Encryption key:off
          Link Signal level:-55 dBm  Noise level:-80 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:103  Invalid misc:0   Missed beacon:0

root@buffalo12:~#

Above is after a 30 hour, near to 100% load, so excessive retries are really like a normal vaue.
Both antennas are aligned as per NetStumbler's readings !
So my question is : Is there anything I can do to get the maximum throughput of ~20mbits/sec over the whole distance ?
Thanks a lot in advance !
And oh, thanks a lot for the GREAT job with OpenWRT !

(Last edited by jailbreaker on 18 Mar 2007, 11:39)

please report what 'wl rate' reports as modulation speed.

With the kind of signal strength that you have you should be getting the full 54 Mbps modultion rate.
That is never the real throughput as the system has overhead and is working half-duplex, i.e. either transmitting or receiving, so the 54 Mbps medium is only available 'part-time'.

If you see lower values of modulation than that is indicative of noise on the channel.
What do you see with 'wl scan ; sleep 1 ; wl scanresults' as command ? Can be given direct from the client; from the ap you first have to temporarily make it a client ('wl ap 0') to be able to scan.
Ideally there should be no other strong signals 2 channels up and down from the used channel as a 802.11g signal is 5 channels wide. Unfortunately you won't see this way any ap with beacon switched off, so what you see is best case, reality may be worse. I have only experience with wrt54g(l) Linksys units and on those an 80 dBm noise reading would also indicate presence of other signals. Here noise readings in the 90-95 dBm are typical for a clear channel.

Another good indicator of link quality is doing pings from one side to the other for a while and observe the time readings. They should be nicely constant and in the 1.8-2.2 ms realm. If there are many higher values than that also indicates interference because apparently re-transmissions are made before even the brief ping packet gets across undamaged.

For your reference; with almost identical antennas (my 80 cm parabola feeds are of a short yagi type) and similar power I bridge 7.5 km at 54 Mbps modulation rate.

Another thing:
1 km should be within what the standard protocol timing allows for, so no distance setting needed. If you do anyway I think you should set the one-way distance.

(Last edited by doddel on 17 Mar 2007, 12:12)

Sorry to jump on this post as a "first post", but I might contribute my experience which is very similar to jailbreaker's.

I have a 7km link with 15dBi antennas (yagi, hand tuned) and power output of 35mW (buffalo whr-hp-g54).

The reported RSSI is -53dBm and signal noise varies between -79dBm and -85dBm depending on the day of week (on weekends SNR improves and during weekdays it worsenes).

Some of the noise might be because of other antennas (2.4Ghz wifi) which are installed on the same towers.

The link sync speed varies between 1Mbps with rain to 5.5Mbps on a perfect day. The Interesting thing is that it will hold sync at up to 48-54Mbps, and will not loose a single packet (even big fat 1500 byte pings), but troughput is only good at the "automaticly" selected rate (indicating that on higher speeds I get retransmissions at the packet level and no errors).

I think the channels are full: Channel 1 and 3 are occupied by other links. I'm transmitting on channel 6. There must be a "hidden" and powerfull link (or noise) on channel 11 as it's impossible to get a sync from channel 9 to 13 included.

(Last edited by mesher on 18 Mar 2007, 09:39)

doddel thanks a lot four your reply !
Here's what 'wl rate' shows on a Sunday morning :

root@buffalo12:~# while true; do wl rate && sleep 30; done
rate is 54 Mbps
rate is 2 Mbps
rate is 54 Mbps
rate is 54 Mbps
rate is 54 Mbps
rate is 54 Mbps
rate is 54 Mbps
rate is 54 Mbps
rate is 54 Mbps
rate is 24 Mbps
rate is 11 Mbps
rate is 54 Mbps
rate is 54 Mbps
rate is 54 Mbps
rate is 11 Mbps
rate is 54 Mbps
rate is 1 Mbps
rate is 1 Mbps
rate is 54 Mbps
rate is 54 Mbps
rate is 54 Mbps
rate is 54 Mbps
rate is 54 Mbps
rate is 48 Mbps
rate is 54 Mbps
rate is 48 Mbps
rate is 54 Mbps
rate is 54 Mbps
rate is 54 Mbps
rate is 54 Mbps
rate is 36 Mbps
rate is 54 Mbps
rate is 54 Mbps
rate is 54 Mbps
rate is 1 Mbps
rate is 54 Mbps
rate is 54 Mbps
rate is 54 Mbps
rate is 48 Mbps
rate is 54 Mbps
rate is 54 Mbps
root@buffalo12:~#

That is -- sync rate drops occasionally.

Client side 'wl scan' (unnecessary stuff removed, sorted by channel number):

root@buffalo12:~# wl scan ; sleep 1 ; wl scanresults
SSID: "E296BA104522C54C67F8E374FC2A857A"
Mode: Managed   RSSI: -85 dBm   noise: -94 dBm  Channel: 1

SSID: "wb-1-slat"
Mode: Managed   RSSI: -76 dBm   noise: -92 dBm  Channel: 2

SSID: "01" <THAT'S ME>
Mode: Managed   RSSI: -54 dBm   noise: -92 dBm  Channel: 2

SSID: "OBELIA"
Mode: Managed   RSSI: -88 dBm   noise: -92 dBm  Channel: 2

SSID: "che_plamen_PtP"
Mode: Managed   RSSI: -66 dBm   noise: -92 dBm  Channel: 4

SSID: "Murchy"
Mode: Managed   RSSI: -87 dBm   noise: -92 dBm  Channel: 4

SSID: "WLAN"
Mode: Managed   RSSI: -88 dBm   noise: -92 dBm  Channel: 6

SSID: "p2"
Mode: Managed   RSSI: -66 dBm   noise: -94 dBm  Channel: 7

SSID: "evisia-slatina"
Mode: Managed   RSSI: -81 dBm   noise: -83 dBm  Channel: 8

SSID: "ANUBA"
Mode: Managed   RSSI: -87 dBm   noise: -80 dBm  Channel: 9

SSID: "123789"
Mode: Managed   RSSI: -78 dBm   noise: -80 dBm  Channel: 9

SSID: "TEA"
Mode: Managed   RSSI: -87 dBm   noise: -81 dBm  Channel: 10

SSID: "linksys"
Mode: Managed   RSSI: -87 dBm   noise: -81 dBm  Channel: 10

SSID: "WAN2"
Mode: Managed   RSSI: -88 dBm   noise: -90 dBm  Channel: 11

root@buffalo12:~#

Which, if I read this correctly, points to channel 11 as a better choice than 2 Which BTW reminds me to ask /offtopic/ -- How to 'enable' channels 12 and 13 in x-wrt ? ( I have wl0_country_code=JP, wl_country=Japan, wl0_country=Japan on both units)

I'll do a 'wl scan' from the ap side soon, but I have the dreaded crash and reboot problem, which may cause /me walking to the other side of the link to reboot the client router

Ping times are ok, according to me. Less than 2ms most of the time, but vary with time of day and day of week - worst for the last two days is 14.6ms.

And regarding the distance parameter -- from what I've read it has to be set to twice the link distance, even the x-wrt interface states this clearly.

(Last edited by jailbreaker on 18 Mar 2007, 10:09)

1. Regarding distance setting following is the case:
in wificonf.c (which produces the wifi binary) the register setting for timing is calculated as follows:

        if (v = nvram_get(wl_var("distance"))) {
                 val = strtol(v,NULL,0);
                 val = 9+(val/150)+((val%150)?1:0);

i.e. the basic 9 microseconds is incresed with distance/150.
In 1 microsecond the radio wave travels 300 meters. Assume the distance setting to be one-way distance, then distance/300 would add the microseconds for one-way; but the formula already accounts for the return distance by only dividing by 150. So the comment on the x-wrt screen is WRONG if the entry on the management screen is directly put in the nvram wl0_distance parameter.

2. set the country to ALL and do so before attempting channel changes. ALL enables ch 1-14.

3. agree that e.g. channel 12 may work better. Channels 4,7,8 & 9 carry strong signals.
In my experience you may also see interference from other users of the spectrum. Notorious problem causers are these AV links to connect a video source to a television elsewhere; they are FM transmitters on 2.4 GHz often cheap and unstable and sweeping through the band. Microwave ovens are the other polluter. But that's why it is ISM band and license free; no pay - no unique use, unlike gsm.

4. have you made sure that the distance setting is active on both units ?
I've a little binary, 'sdist' , that shows the register settings. Put it in //usr/sbin, make it executable, and you'll see the relevant register values. http://www.dorpstraat.com/OpenWrt/sdist
One is 9 microsec plus the extra time, the other is 510 (both decimal, but reporting is in hex) plus the extra time.
There is an issue with this setting in that as a result of autonomous actions by the broadcom proprietary radio driver wl.o, e.g. when (re-)associations occur, the timing gets reset to the basic one. As part of the watchdog cycle wifi regularly updates these registers but there may be brief intervals during which they are wrong. This may explain the drops in datarate that you see. You may do the 'wl rate' test again and add the sdist reporting to see whether momentary changes in distance setting correlate with drops in datarate.

(Last edited by doddel on 18 Mar 2007, 13:01)

doddel, d00d 10xalot for helping so much !
Here are my comments :
1. You're darn right ! x-wrt is wrong, as it sets the value you enter in the web interface directly to wl0_distance. Thanks for clearing this out.

2. Thanks for the advice, though I had some trouble figuring out which has to be set to 'All" -- wl0_country, wl0_country_code or both. Ended up setting both, and it works ok.

3. Switched to channel 14, as it seemed like the channel 'farthest' away from any other traffic. Client side 'wl scan' shows (again bullshit removed, sorted by channel) :

root@buffalo12:~# wl scan; sleep 1; wl scanresults
SSID: "wb-1-slat"
Mode: Managed   RSSI: -78 dBm   noise: -92 dBm  Channel: 2

SSID: "che_plamen_PtP"
Mode: Managed   RSSI: -69 dBm   noise: -96 dBm  Channel: 4

SSID: "p2"
Mode: Managed   RSSI: -64 dBm   noise: -87 dBm  Channel: 7

SSID: "evisia-slatina"
Mode: Managed   RSSI: -81 dBm   noise: -85 dBm  Channel: 8

SSID: "9526"
Mode: Managed   RSSI: -83 dBm   noise: -96 dBm  Channel: 9

SSID: "ANUBA"
Mode: Managed   RSSI: -88 dBm   noise: -96 dBm  Channel: 9

SSID: "01" <THATS ME >
Mode: Managed   RSSI: -57 dBm   noise: -92 dBm  Channel: 14

root@buffalo12:~#

AV xmitters are not very popular around here, so I do believe that no interference is coming from such devices, but you never really know, don't you Another thing is that channel 14 is a bit outside the legal spectrum in Bulgaria (1-11 IIRC), so maybe other sources add noise. Will try hopping through the other "high" channels (12,13) when I have some spare time.

4. Here's the test again w/ 'sdist' output added, again ran on the 'client' router :

root@buffalo12:~# while true; do (wl rate;sdist;sleep 5); done
rate is 5.5 Mbps
shm: 0x10
reg 684: 0x207
rate is 1 Mbps
shm: 0x10
reg 684: 0x207
rate is 5.5 Mbps
shm: 0x10
reg 684: 0x207
rate is 1 Mbps
shm: 0x10
reg 684: 0x207
rate is 11 Mbps
shm: 0x10
reg 684: 0x207
rate is 11 Mbps
shm: 0x10
reg 684: 0x207
rate is 1 Mbps
shm: 0x10
reg 684: 0x207
rate is 11 Mbps
shm: 0x10
reg 684: 0x207
rate is 18 Mbps
shm: 0x10
reg 684: 0x207
rate is 36 Mbps
shm: 0x10
reg 684: 0x207
rate is 36 Mbps
shm: 0x10
reg 684: 0x207
rate is 54 Mbps
shm: 0x10
reg 684: 0x207
rate is 54 Mbps
shm: 0x10
reg 684: 0x207

root@buffalo12:~# nvram show | grep distance
wl0_distance=1000
size: 9147 bytes (23621 left)
root@buffalo12:~#

sdist values don't change, but I don't really know how to interpret this output.

BTW -- with your 7.5 km link and the routers syncing at 54mbps, what is the real thoughput you get ? I'm still hoping to get at least 15mbits/sec real badwidth over my miserable 986 meters, thought evidence starts to show a bit different reality
Anyway, thanks again for your great help -- nice talking to you !

good to see that the modulation now gets towards the 54 Mbps.
Actually you should do the measurement in presence of real traffic so you may add add a 'ping -c 1 <ipaddress of the other side>' command to the test cycle to generate traffic. In absence of traffic the radio communication quality statistics easily look bad due to received noise and interference and the driver reduces rates in reaction to that. The distance setting looks to be ok and stable, but you need to check on both sides !

The 1 Mbps values are of course very bad; are you indeed using identical settings on both ends of the link, apart from one side ap and the other client ? Values of 1 and 2 Mbps I only see here when there is a timing issue but with your short distance and very strong signal this shouldn't happen. If all settings would be ok I can only explain it from the presence of very strong interference.

Effective datarates that I get here, e.g. transferring a file from one router to the other using wget, over the 7.5 km distance are in the 20-24 Mbps realm. We transport two adsl2+ 8 Mbps accesses over one such radio link.

After 'walking' through all channels I noticed that upper  ones are much more susceptible to noise -- couldn't get a stable sync at 54mbps at 12, 13 and 14 -- got 18-48 most of the time, and did scanning/testing/tuning mostly at night, when noise is at it's lowest. Now I reverted back to channel 2, which got me a stable link at 54mbps, but real data throughput is still in the ~10Mbit/sec (at max) range
The final thing coming to my mind to try is to use horizontal polarization. This reminds me to ask what polarization does the biquad have when the 'leaves' of the antenna are located like the infinity symbol (a laying '8'), in relation to the ground (damn good explanation, isn't it) ? IIRC '8' is horizontal and a laying '8' is vertical.
So I'll try rotating my feeders 90 degrees and report back any success, if any. Thanks for your help !

(Last edited by jailbreaker on 22 Mar 2007, 23:07)

Bi-quad feed: the polarization is such that looking at the antenna from the front, if the squares are placed side by side the polarization is vertical.
So to do H polarization rotate by 90 degrees, i.e. the squares are one above the other.