Hi,

I'm writing this post with the hope to "sensibilize" openwrt users and developers to spend more effort on long distance link optimization. Let's me explain.

Five years ago I made my first long distance link. The link is 4.1 km, so it's not so long, but I live in a rural site with no DSL service (and no hope to have it soon, that's Italy!) and so I use it to bring DSL connection, and I need to have the maximum possible throughput.

At first time I used two WRT-54GL, replaced times later with the optimum WHR-HP-G54 (one of the best cheap hardware with very powerfull rf txpower), two 24 db grid antenna. As firmware I used first sveasoft (I know, it's closed, but it was the only firmware having the most recent wireless drivers for broadcom) and then dd-wrt. With this hardware/software configuration, using channel 14 (in Europe is not legal, but it's the only real clear channel), fixed rate and shortslot_override I'm able to have a real throughput of 1.2 MB/s with fixed low latency of 1-2 ms and rssi of -68.

Later I made a second long distance link of 3.5 km (yeah, it's not so long also this), in this case using a couple of Uibuiquiti NanoBridge 5 GHz 22 db, with OpenWRT (trunk compiled by myself, in the meanwhile I abbandoned dd-wrt for the normal routing operation, preferring openwrt). In this scenario, with a rssi of -74 I have a stable link and a real throughput of 3 MB/s.

So, two weeks ago, I replaced my old 2.4 link with a new one 5 Ghz. First using Ubiquiti NanoBridge 5 Ghz 25 db (despite of distance I need high gain due of some trees in the los) and then, because of the low received signal (-83), two Rocket M 5 Ghz and two RocketDish 30 db. This is the final rssi

     LinkName XX:XX:XX:62:35:AB -74 dBm -95 dBm 52.0 Mbit/s, MCS 11, 20MHz 39.0 Mbit/s, MCS 10, 20MHz
     LinkName XX:XX:XX:62:35:82 -76 dBm -95 dBm 52.0 Mbit/s, MCS 11, 20MHz 39.0 Mbit/s, MCS 10, 20MHz

this the the test speed

root@OpenWrt:/# ttcp -r -s -v
ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5010
ttcp-r: start time Sun Jul 21 11:15:55 2013
ttcp-r: File-Descriptor 0x3 Opened
sockbufsndsize=16384, sockbufrcvsize=87380, sockbufsize=51882,
# tcp receiver #
ttcp-r: accept from 172.20.0.1
ttcp-r: 16777216 bytes in 23.052525 real seconds = 710.725 KB/sec +++
ttcp-r: 16777216 bytes in 1.390000 cpu  seconds = 11.511 MB/cpu sec
ttcp-r: 5753 I/O calls, 4.007 msec(real)/call, 0.242 msec(cpu)/call
ttcp-r: 0.070000user 1.320000sys 0:23real 6.0% 0i+0d 166maxrss 0+5pf 5420+92csw
ttcp-r: buffer address 0xc14000
ttcp-r: File-Descriptor  fd 0x4 Closed

and the latency of the link is quite unstable

Risposta da 172.20.0.1: byte=32 durata=2ms TTL=64
Risposta da 172.20.0.1: byte=32 durata=1ms TTL=64
Risposta da 172.20.0.1: byte=32 durata=4ms TTL=64
Risposta da 172.20.0.1: byte=32 durata=5ms TTL=64
Risposta da 172.20.0.1: byte=32 durata=30ms TTL=64
Risposta da 172.20.0.1: byte=32 durata=8ms TTL=64
Risposta da 172.20.0.1: byte=32 durata=31ms TTL=64
Risposta da 172.20.0.1: byte=32 durata=1ms TTL=64
Risposta da 172.20.0.1: byte=32 durata=24ms TTL=64
Risposta da 172.20.0.1: byte=32 durata=16ms TTL=64
Risposta da 172.20.0.1: byte=32 durata=8ms TTL=64
Risposta da 172.20.0.1: byte=32 durata=2ms TTL=64
Risposta da 172.20.0.1: byte=32 durata=53ms TTL=64
Risposta da 172.20.0.1: byte=32 durata=12ms TTL=64
Risposta da 172.20.0.1: byte=32 durata=1ms TTL=64
Risposta da 172.20.0.1: byte=32 durata=11ms TTL=64
Risposta da 172.20.0.1: byte=32 durata=3ms TTL=64
Risposta da 172.20.0.1: byte=32 durata=7ms TTL=64
Risposta da 172.20.0.1: byte=32 durata=47ms TTL=64
Risposta da 172.20.0.1: byte=32 durata=5ms TTL=64
Risposta da 172.20.0.1: byte=32 durata=2ms TTL=64
Risposta da 172.20.0.1: byte=32 durata=39ms TTL=64
Risposta da 172.20.0.1: byte=32 durata=2ms TTL=64
Risposta da 172.20.0.1: byte=32 durata=52ms TTL=64
Risposta da 172.20.0.1: byte=32 durata=5ms TTL=64
Risposta da 172.20.0.1: byte=32 durata=1ms TTL=64
Risposta da 172.20.0.1: byte=32 durata=5ms TTL=64
Risposta da 172.20.0.1: byte=32 durata=13ms TTL=64
Risposta da 172.20.0.1: byte=32 durata=7ms TTL=64
Risposta da 172.20.0.1: byte=32 durata=28ms TTL=64
Risposta da 172.20.0.1: byte=32 durata=13ms TTL=64
Risposta da 172.20.0.1: byte=32 durata=35ms TTL=64
Risposta da 172.20.0.1: byte=32 durata=1ms TTL=64
Risposta da 172.20.0.1: byte=32 durata=7ms TTL=64
Risposta da 172.20.0.1: byte=32 durata=1ms TTL=64
Risposta da 172.20.0.1: byte=32 durata=20ms TTL=64
Risposta da 172.20.0.1: byte=32 durata=16ms TTL=64
Risposta da 172.20.0.1: byte=32 durata=3ms TTL=64
Risposta da 172.20.0.1: byte=32 durata=3ms TTL=64

So with more expensive and powerful hardware I have worst results, in terms of latency and throughput. So I decided to rollback to airOS, and this is the result (using same channel and same configuration)

speedtest

root@DbfNas:~# ttcp -r -s -v
ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5010
ttcp-r: start time Tue Jul 30 12:31:50 2013
ttcp-r: File-Descriptor 0x3 Opened
sockbufsndsize=16384, sockbufrcvsize=87380, sockbufsize=51882,
# tcp receiver #
ttcp-r: accept from 172.20.0.1
ttcp-r: 16777216 bytes in 4.872735 real seconds = 3.284 MB/sec +++
ttcp-r: 16777216 bytes in 0.530000 cpu  seconds = 30.189 MB/cpu sec
ttcp-r: 10233 I/O calls, 0.476 msec(real)/call, 0.052 msec(cpu)/call
ttcp-r: 0.070000user 0.460000sys 0:04real 10.9% 0i+0d 166maxrss 0+5pf 9714+68csw
ttcp-r: buffer address 0x9bc000
ttcp-r: File-Descriptor  fd 0x4 Closed
ttcp done.

pingtest

Risposta da 172.10.0.1: byte=32 durata=1ms TTL=64
Risposta da 172.10.0.1: byte=32 durata=1ms TTL=64
Risposta da 172.10.0.1: byte=32 durata=1ms TTL=64
Risposta da 172.10.0.1: byte=32 durata=1ms TTL=64
Risposta da 172.10.0.1: byte=32 durata=1ms TTL=64
Risposta da 172.10.0.1: byte=32 durata=2ms TTL=64
Risposta da 172.10.0.1: byte=32 durata=2ms TTL=64
Risposta da 172.10.0.1: byte=32 durata=1ms TTL=64
Risposta da 172.10.0.1: byte=32 durata=1ms TTL=64
Risposta da 172.10.0.1: byte=32 durata=1ms TTL=64
Risposta da 172.10.0.1: byte=32 durata=1ms TTL=64
Risposta da 172.10.0.1: byte=32 durata=1ms TTL=64
Risposta da 172.10.0.1: byte=32 durata=1ms TTL=64
Risposta da 172.10.0.1: byte=32 durata=1ms TTL=64
Risposta da 172.10.0.1: byte=32 durata=1ms TTL=64
Risposta da 172.10.0.1: byte=32 durata=1ms TTL=64
Risposta da 172.10.0.1: byte=32 durata=1ms TTL=64
Risposta da 172.10.0.1: byte=32 durata=1ms TTL=64
Risposta da 172.10.0.1: byte=32 durata=2ms TTL=64
Risposta da 172.10.0.1: byte=32 durata=1ms TTL=64
Risposta da 172.10.0.1: byte=32 durata=2ms TTL=64
Risposta da 172.10.0.1: byte=32 durata=1ms TTL=64
Risposta da 172.10.0.1: byte=32 durata=2ms TTL=64
Risposta da 172.10.0.1: byte=32 durata=4ms TTL=64
Risposta da 172.10.0.1: byte=32 durata=1ms TTL=64
Risposta da 172.10.0.1: byte=32 durata=1ms TTL=64
Risposta da 172.10.0.1: byte=32 durata=1ms TTL=64
Risposta da 172.10.0.1: byte=32 durata=1ms TTL=64
Risposta da 172.10.0.1: byte=32 durata=10ms TTL=64
Risposta da 172.10.0.1: byte=32 durata=2ms TTL=64
Risposta da 172.10.0.1: byte=32 durata=1ms TTL=64
Risposta da 172.10.0.1: byte=32 durata=1ms TTL=64
Risposta da 172.10.0.1: byte=32 durata=1ms TTL=64
Risposta da 172.10.0.1: byte=32 durata=1ms TTL=64
Risposta da 172.10.0.1: byte=32 durata=1ms TTL=64
Risposta da 172.10.0.1: byte=32 durata=2ms TTL=64
Risposta da 172.10.0.1: byte=32 durata=1ms TTL=64
Risposta da 172.10.0.1: byte=32 durata=1ms TTL=64
Risposta da 172.10.0.1: byte=32 durata=1ms TTL=64
Risposta da 172.10.0.1: byte=32 durata=1ms TTL=64

Obviously with openwrt I set the distance, and tried also Attitudine Adjustment build, with no luck. This test tell that in this particular scenario openwrt is not mature for long distance link, and I have to use airOS, with regret. I hope that will be spent more effort on long distance link, as well as created a dedicated section for ldl on the forum.

Then I have a last question, that i know has already been discussed but the final response is not clear to me: I'm in Italy, I can use channel 13 of 2.4 Ghz here. Why I'm unable to use it, except of using hack methods?

Thanks in advance
FunMan

It's not the firmware, mount your diectional antena as high as you can, the two antanas can see each other dircetly with no block in between, then all your speed should come back, based on "low noise" of course.

Dear eeff11,

i'm not glad to say that is a firmware (openwrt in this case, the firmware that normally I use) problem, but this is the truth. Not a general firmware issue, simply airOS has some optimization for long distance link that openwrt didn't.

I'm not a beginner in ldl, all you say is correct, but you must consider that antennas position is the same (fixed) between the two test case, and only changing the firmware from openwrt to airos I have different results (same as rssi, different for throughput, 700 kb/s with openwrt and 3 MB/s with airos).

FunMan

(Last edited by FunMan on 30 Jul 2013, 16:45)

If you have ubnt device and do not anything extra, stick with AirOS, it's way faster and perfectly stable. AirOS has some scripting support too, but openwrt has much more possibilities at the cost of lower throughput, higher latency and buggy wifi

On a regular basis some guy comes to this forum and brags that AirOS is more beautiful then OpenWrt. And I hav no idea whether this claims are true or not!

What I do know, is that I can purchase some Mainboard with a Bobcat-CPU for 50 Euros.
http://geizhals.de/?cat=mbson&xf=11 … amp;sort=p
Add 25 Euros for 4GiB of DDR3-RAM.

Or buy a Cubieboard for 50 Euros.

FOSS software is already available and at least the Radeon-FOSS-driver is pretty good.

So why do some routers cost 100 Euros or more :-O Is the work done on them sooo valuable, or is it just, "the management" isn't capable of producing products that sell often enough, so that you can offer decent prices?

Bobcat-Mainboard = 50 and I can go to Internet with it.
Some cheap Tp-Link Router: 15 Euros, and again, I can go to Internet with it.

What is soo much better about the "more beautiful" devices/OSes, that justify the much higher price?

If you really believe that the ath9k (or any other) driver can be written in a different manner and that this will result in soo much better distance(?) or stability or jitter or what not, find somebody capable of implementing this. Then pay the guy(s) to actually do it.

Many projects implementing OpenWrt don't even bother to mention this fact clearly: "Hey, we took this software (equivalent in 00x.000 man hours of work on the Linux kernel, x.000 man-hours of work for the OpenWrt framework) added x00 man-hours of work to it, and this is the result.

Maybe AirOS is more beautiful then OpenWrt. Dunno.

From his post history it doesn't appear that he is a shrill or troll.
I think we should take a more moderate approach towards negative opinions.
Accepting constructive opinions will only serve to strengthen the project rather ignoring or brushing them off.

And I do, he? ;-)

I do not see the constructiveness in the post. Then of course I am neither a programmer not an electrical engineer.

I just do not see how software could affect range. Stability, delay, jitter, yeah of course, but range? Even if the claim is true, I see little value in it. And then again, it's just a claim!

I'd like to see two meshes and/or two single "long distance" link, one with OpenWrt the other with AirOS and see what's what.

Gee, isn't there this ballte-mesh thingy, where people could actually really prove stuff? Did ubiquity participate and PROVE that their software is better on identical hardware? No? Why not? Would be better and more professional then such a forum troll.

kirschwasser,

honestly I don't understand the sense of your post. Do you think that I'm in this forum because I have no better way to spend my time?

In my opinion openwrt is one of the best project I saw, with a lot of potentiality, I follow the project and I support it as I can, but it would be a curious experiment of masochism the use of openwrt on my long distance link, when the real throughput with the same hardware and configuration was about 1/4 of the airos one. Were up to me I will use it on all my lan devices (and infact this is, except the main long distance link, for the reason I explained). I found an objective performance issue on long distance link and I'd like that would be spent more effort, if possible, to optimize this particolar implementation. It's not a must, only an hope.

I know that openwrt uses ath9k drivers and airos hacked madwifi, and I know perfectly that the first is the right choice to have an always updated kernel, so as I know that "hacking" (or optimizing if you prefer) ath9k is not so simple.

Long distance link is a niche stuff, and major efforts are spent for "normal use" functions. It's normal. But I hope that some improvments can be achieved also on ldl.

FunMan

(Last edited by FunMan on 31 Jul 2013, 17:07)

I made latency and throughput test on the same 4.1 link. Same position, same hardware. Only firmware was different, and with openwrt I have worse results. This is ojective, you can not verify and you have to trust me but I have no interest indeed to support here a false thesis.

I'd like to have openwrt on my hardware, instead of airos

FunMan

Do you have your /etc/config/wireless file?

No,

I have airos now, I did not saved it. If you need some info I can try to remember... configuration was quite simple, automatic (default) rate, wpa2 psk and 4100 meter as distance optimization... tried also different values with no luck.

Funman

Did you try dtim_period, noscan?
There are some options not specified in LuCI.

No... where can I find information about them? and there'is a way to switch from airos to openwrt (and viceversa) not using the reset button of ubiquiti? a sort of secure mtd way... this is production scenario, I can flash but I have to do it quickly and possibly without go to remote location...

Thanks
FunMan

http://wiki.openwrt.org/doc/uci/wireless
Look under all the ath9k/mac80211 options.

(Last edited by alphasparc on 31 Jul 2013, 18:25)

Although I'm almost a year late to the discussion, I wanted to second FunMan's original idea of paying more attention to Long Distance Links (LDLs) using OpenWRT.

I have been trying to set up a 5-mile encrypted link with OpenWRT on Ubiquiti gear and have, so far, been unsuccessful. I know plenty about radios, antennae, Fresnel zones, and all that electromagnetic stuff - all that's fine, but I can't get the software to actually pass data across the link.

I appreciate the suggestion of using dtim_period and noscan, although it's not entirely clear how they'd help if there's no link currently.

Unfortunately, testing this is difficult: I have a good 5-mile testing range, but I can't run a test there in less than half a day, and it takes at least 20 minutes to go from one end of the range to the other (mountaintops: great for Fresnel zone, usually crummy for access).

I'd love to help figure out LDLs in OpenWRT. There may need to be changes to the software, or it may just need a Wiki page, but I think it's an important thing to get done.

All assistance will be met with gratitude.

-Bill