Bullet M - latency, lockup and aggregation aggravation

[rcosby]

Well, our first test of the BulletM5HP with live traffic was disappointing.

We're running the latest beta firmware (the one that is supposed to fix the ethernet lock). 7 mile link, 29dbi solid dishes. Replacing a trango 45 link. Pushing up to 15 meg peak. Average under 10meg.

-96 noise floor, -68 link. 20mhz channels.

Our initial concern was about latency. It would sit around 3-4ms, but then get up to 100+ms from time to time with heavy traffic (10megabit or so). CCQ would also jump around from 100 to sometimes 40%.

We tried different channels and saw little difference. Tried shutting off aggregation and lost the link. Eventually by turning aggregation on at one side we were able to get enough traffic through ( with 1000+ms latency) to get the page up on the other side and turn it back on. Still no good link. Rebooted near side a couple times, and eventually just changed channels and got back up.

Earlier this morning, before making these changes, we were unable to reach either side. Power cycled near side and they came up.

We're seeing strange problems after changes where we can't reach some IP's on far side, but can reach others, and traffic is flowing. For example, I have an AP on the other side. Can't reach that, but a subscriber behind that AP is reachable.

Anyway, I'm up and somewhat stable right now other than occasional latency issues. The lockup we had this morning caused us to plan to take this link back down and put the Trango back up. If the far side locked up it would be much harder to fix. Hopefully with time these will become more stable and usable for backhauls.

Randy

[UBNT-Mike.Ford]

Well, our first test of the BulletM5HP with live traffic was disappointing.

We're running the latest beta firmware (the one that is supposed to fix the ethernet lock). 7 mile link, 29dbi solid dishes. Replacing a trango 45 link. Pushing up to 15 meg peak. Average under 10meg.

-96 noise floor, -68 link. 20mhz channels.

Our initial concern was about latency. It would sit around 3-4ms, but then get up to 100+ms from time to time with heavy traffic (10megabit or so). CCQ would also jump around from 100 to sometimes 40%.

We tried different channels and saw little difference. Tried shutting off aggregation and lost the link. Eventually by turning aggregation on at one side we were able to get enough traffic through ( with 1000+ms latency) to get the page up on the other side and turn it back on. Still no good link. Rebooted near side a couple times, and eventually just changed channels and got back up.

Earlier this morning, before making these changes, we were unable to reach either side. Power cycled near side and they came up.

We're seeing strange problems after changes where we can't reach some IP's on far side, but can reach others, and traffic is flowing. For example, I have an AP on the other side. Can't reach that, but a subscriber behind that AP is reachable.

Anyway, I'm up and somewhat stable right now other than occasional latency issues. The lockup we had this morning caused us to plan to take this link back down and put the Trango back up. If the far side locked up it would be much harder to fix. Hopefully with time these will become more stable and usable for backhauls.

Randy


Hey Randy,

Is this with or without AirMax? Also are you using AutoACK? Have you tried limiting maximum data rates?

Thanks,

Mike

[rcosby]

Without AirMax. Using AutoACK. Have not tried limiting max data rates.

[rcosby]

Just turned autoping on the far side for a safety measure. After the change, link went down for a few seconds. Now back up but not able to reach anything behind the link.

[rcosby]

Power cycled near end, no help. Rebooted far end, and stuff came back.

I noticed there was only one entry in the bridge table on the far side (the gateway), but lots on the near side when this problem happened. Now both tables have lots of entries.

[rcosby]

I'm seeing conflicting information.

In the wiki, it says for ptp links, to set the AP as AP WDS, and the station as "Station".

In forum postings, I've seen mike say to set them to AP WDS and Station WDS.

Which is it? I'm passing vlans, etc... Currently set to AP WDS and Station WDS.

Randy

[drwho17]

Should be WDS on both sides to function as a transparent bridge.

[avantwireless]

I'm seeing conflicting information.

In the wiki, it says for ptp links, to set the AP as AP WDS, and the station as "Station".

In forum postings, I've seen mike say to set them to AP WDS and Station WDS.

Which is it? I'm passing vlans, etc... Currently set to AP WDS and Station WDS.

Randy

Randy,
If you are routing over a 802.11 link you need to use WDS modes ( AP WDS and Station WDS) in order to properly pass all frame information from devices on either side. We have not seen anyone with good results without AirMax... Suggest you try it too...

[UBNT-Edmundas]

Well, our first test of the BulletM5HP with live traffic was disappointing.

We're running the latest beta firmware (the one that is supposed to fix the ethernet lock). 7 mile link, 29dbi solid dishes. Replacing a trango 45 link. Pushing up to 15 meg peak. Average under 10meg.

-96 noise floor, -68 link. 20mhz channels.

Our initial concern was about latency. It would sit around 3-4ms, but then get up to 100+ms from time to time with heavy traffic (10megabit or so). CCQ would also jump around from 100 to sometimes 40%.

We tried different channels and saw little difference. Tried shutting off aggregation and lost the link. Eventually by turning aggregation on at one side we were able to get enough traffic through ( with 1000+ms latency) to get the page up on the other side and turn it back on. Still no good link. Rebooted near side a couple times, and eventually just changed channels and got back up.

Earlier this morning, before making these changes, we were unable to reach either side. Power cycled near side and they came up.

We're seeing strange problems after changes where we can't reach some IP's on far side, but can reach others, and traffic is flowing. For example, I have an AP on the other side. Can't reach that, but a subscriber behind that AP is reachable.

Anyway, I'm up and somewhat stable right now other than occasional latency issues. The lockup we had this morning caused us to plan to take this link back down and put the Trango back up. If the far side locked up it would be much harder to fix. Hopefully with time these will become more stable and usable for backhauls.

Randy

Looks like ACK timeout configuration issues. Please try to turn off AutoACK and set ACK timeout for a little bit higher distance manually and do tests again.

[dave@skywireusa.com]

randy good to see that I am not the only having this exact issue

[UBNT-Mike.Ford]

Hey Guys,

Please disable the AutoACK feature and set the ACK distance to 125% of the actual link distance and test from there. Also please make sure aggregation is turned on and at 50000.


Thanks,

Mike