Backhauls have poor downlink % and some Queue Overflows????

Hey everyone,

I have a new link going up here, I took me a while but I found a channel without interference, or so I think…

The link is only 5 mi. (just under) and I’m using 5.7 with version 7.x.x. I probably need to fine-tune the alignment better but was wondering if anyone might have input on the fact that BOTH backhauls get exactly 46% downlink, and 100% uplink. I have tried all the variations I can think of… (changing 1x to 2x, then to software scheduling 10mb to 20mb) and they still get about 40-50% donwlink and 100% uplink. I tried low power but that didn’t work at all. Any ideas?

Hi LP,

First thing that comes to mind is noise at the BHS side.

I have been looking through the backhauls and found the following under “down stat”…

RF Fragments Transmitted
14365
Fragments Successfully Transmitted
6984
Air Travel Delay Time
483
Data Lost (Queue Overflow)
10776

The Queue Overflow seems to me to be a high number. I have been searching for a reason for this, but haven’t found anything Canopy specific. Could this be my problem?

Another note: My Jitter stays 4 and bellow - but it’s constantly bouncing between 1 and 4.

I can’t find anything else that stands out. I can mention that for now, the slave is on a tower with 4 other backhauls that are masters. I made this one a slave for aiming purposes- I know that they should all be masters (or have heard such) on the same tower and intend to change them to that- but wanted to fix the link first. Unless that might be the problem as well>?

Thanks much!

What bands are the other 4 BH’s in?

Are there 5.7AP’s on the same tower? How many?

Are you running Sync on all BH’s and AP’s that are in 5.7 on that tower and any towers within 5 miles?

You may have a crowding/sync issue

They are definately crowded… the other towers are running 5.7 and all together there are about 5 (but all in opposites about. I did see another AP eval that showed an unknown 5.7 only 10mhz form mine. I wasn’t sure if that was the case though. All are times via a CMM micro.

thanks.

Try http://ipofthebackhaul/configuration.html. On the slave side check all the frequencies, and on the master side try some other 56xx mhz frequency. This could be illegal, but for testing it will do the job and you will know it there is a frequency issue.

Erkan’s idea is a good one. It will move the BH out of the spectrum giving you an opportunity to determine if the problem is spectrum or something else.

You need to flip your BHM and BHS so that all the masters are on the same tower running the same GPS sync, Software Version, and DL%. If they are co-located with other 5.7 AP’s then it will be interesting to see if you can get everything working together.

Regarding that “other” AP that is 5 miles away: Find the person running it and get them to either use an SM to sync off your tower, or add a CMM or SyncPipe. They should also have their AP set to the same DL%, Max distance, and #Ctrl Slots to minimize inter-tower interference.

I will switch the BHM and BHS - to reflect the preffered setup. However, I don’t understand how I could select a freq outside 5.735-5.835 as those are the only options?

thanks again.

Go to http://radioip/configuration.html

There you will find the alternate frequencies. You cannot leave the radios on these freqs, use for testing only.

Thanks for the help! I didn’t know about that page, are there any others?

I looked at that and had no solution, but when I changed the master to this side (the side with the other masters on it with a CMM doing timing) the link came up, and then switching to hardware finished the deal.

Now, I did have a question, is there any reason to run software scheduling instead of hardware? Most of our back-hauls are on Hardware as I know it supposed to be better, but some are on software. these links have about 1200 rssi and excellent db (60ish) wikth good jitter as well. Since I have been picking up this network for about 4 months I’m to the point were I might want to put those on hardware to be uniform in the network- but I’m not sure if it was an oversight or if there are reasons to stay on software. (example- signal gets worse or is not good enough to support hardware)?

Going along with that, if I have two BH that are about 1160 rssi with strong signals and low jitter- would it kill the link by putting them in 2x (20mb). they are 20mb back-hauls but this is another reason I don’t know if they are set to half for a reason, or none.

basically, (after all that) if the link works in software, should it in hardware- and at 1200ish rssi with good dbm, should 20mb work as 10 did? not sure how high the rssi should be before pursuing the 20mb as I imagine it needs to be a better aim.

Thanks again people. This forum is an invaluable tool as they always are!

Uniformity is crucial. Ideally all co-located BH’s and AP’s in a given band will run the same
- software version
- scheduling
- DL %
- # control slots (AP’s)
- max distance

You can use the Scheduling Tool in the radios to determine the optimum settings. Refer to the manual or do a forum search on using the Scheduling Tool.

P8 radios can only run SW scheduling. If you have most radios in HW scheduling and you throw in a SW scheduling radio you can create self-interference issues. Also there are issues with SW scheduling BH’s running 7.2.9 or 7.3.6 that are co-located with AP’s in the same band. There is a note in the Knowledge Base.

With Advantage radios; if you enable 2X the link will try to connect at 2X and if it can’t it will auto-negotiate to 1X. Non advantage in 2X will just drop the link.