Hello all,

My first post was about what is needed to setup a real backhaul for a DS3. This post was started once I was convinced my hardware setup should be good enough thanks to all your input.

Summary:
nstreme 2 on a 3mile link
using 2 rb333, 4 R52, 4 29dbi solid dish, 4ft Andrews LMR400 nmale patch cables.
26V POE powered, 4 ft separation on dishes.
top dishes VPOL on 5GHz turbo, 5210
Bottom dishes on HPOL on 5GHz turbo, 5610

http://www.dfxden.com/images/forumpics/ ... config.JPG
Current Config

http://www.dfxden.com/images/forumpics/bothstatus.JPG
Current Status on Each Side

notice the number of errors. What does this mean?

I was going to post all the pics of the speed results, but I am having probs inserting the images, so I'll just tell you them, and if you want to see them let me know.

from RB to RB
UDP send = 47.2
UDP receive = 66.8
UDP both = 38.1/50

from RB to RB
TCP send = 24.1
TCP receive = 24.9
TCP both = 9.5/16.5

from Computer to Computer things get wierd (this is from P4 to P4 straight to the RBs
TCP both = 8/17
UDP both = 7.5/36.8

So, I am looking for answers to better tune this setup, and improve through to the PC, especially TCP. It's like once traffic starts passing through both the ethernet and wireless the CPU gets slammed. Also, any interpretation for the errors would be cool!
Cheers.

So you are seeing 35mb full duplex with two rb333 using R52 cards?

How has it been running? Well, solid, stable and overall happy?

Thanks,
Scott

Hey Scott,

Sorry, was still editing when you posted. To answer your question... I feel this link should be better, but I have run out of ideas on how to make improvements, especially as it relates to framing policy. Maybe it's good and I'm just expecting too much.

Ron

Ok, this is the config for my last point to point bridge (RB333+R52 on each side).

WDS Bridge
Conntrack disabled
Some packages disabled: ipv6, hotspot, ppp and dhcp
5Ghz Turbo (with -60db signal)
NStreme ON, polling ON, Exact size 3200

Perfect 70 mbps UDP aggregated bandwidth. Really I'm very impressed

can you take a second to expand upon what this means exactly so its not mis-interpreted:

70 mbps UDP aggregated bandwidth

Thanks
Scott

can you take a second to expand upon what this means exactly so its not mis-interpreted:

70 mbps UDP aggregated bandwidth

Thanks
Scott

send + receive = aggregated

Is the total traffic in both directions

So basically its a 35mb half duplex link... Thats what I was looking for, thanks.

I am curious why you chose an exact fit framer policy as apposed to no framer policy or best fit. Can you explain why you selected this configuration or did you just test each possible way and this performed slightly better?

Is the framer applied per packet being sent out the wlan interface or does the framer fill up the outgoing "packet" until 3200 is reached then segment the rest into the next frame?

Scott

If he is getting 70Mbps total send + receive, then it's a 70Mbps half-duplex link, or 35Mbps full-duplex link.

this link has been running surprisingly smooth. While I was hoping for a better TCP FD bandwidth, I am finding that since bandwidth consumption is about 70% down and 30% up, that the RB333s are doing just fine in the DS3 backhaul role. I have been graphing the CPU, and we average around 30%. So I am pleased. My ping times are also 2-5 ms to the router 3 miles away, and my bandwidth tests to my house are averaging 20Mbit up and down.

However, for my own knowledge (and probably many of my friends in this online community) can someone explain why I am getting so many tx and rx errors as illustrated in the images?

Also, how does one determine framing policy and Framer limit?

On backhauls, how important is disabling CSMA?

Thanks all!

Cheers

Hey Travis, thats why I asked for clarification so there wasn't any room for assumption. Lots of people explain things different ways.

It would be best to say:
Send: 10
Receive: 10
Both: tx5/rx4

Leaves no room for assumption When he says he has 35 send and 35 receive, it could be each by itself or could be at the same time, which is why I asked for clarification.

Thanks,
Scott

Hi DesertTek,
NStreme2 still has too many secrets to me, I'm starting to "play" with it in these days.
Errors might be related to crosstalk, despite the fact that Rx/Tx are 400MHz spaced and crosspolarization is used. You can try to use RF narrow bandpass filters centered in interest frequencies (5210/5610 MHz). With that
signal level you shoul be able to obtain that throughput also without NStreme2...

Regarding throughput measurement, I think that tcp test is the one to reffer to: NStreme2 is used mainly to have full duplex connections and to lower latency. Traffic sensible to latency is mainly TCP traffic: browsing and VoIP.

I think you never got the performance you wanted because the CPU is just too weak. It's not a wireless problem.

Have you tried locking the speed to 24 megs on both sides?

alright, set the rates to 24/36 only. I never messed with these, because everyone always shouts "Leave at default!" I was usually at 54 with an occasional drop to 48. For the most part it seemed consistant.

But I have to say, ping times are better, stability has improved (still not perfect, but clearly better as it only watchdogged once yesterday) and I'm happier with a little progress. Tests are showing a pretty consistant 30Mbit TCP full duplex connection. This will work now that we decided to set up another backhaul to another tower from the NOC, instead of off the main tower. Our need for a full 45Mbit BH is gone. A FD backhaul for a grand?! take that Moto!

Thanks!

I would continue to play with the speed settings. It is the TX power you need to leave set at default not the speed settings. Most cards drop their power rate when the go to 36 megs. If it will run well at 36 lock it at 36. I wouldn't run it using both 24 and 36.