20.2.1 throughput issue on 5GHz 450m

We had a rather severe throughput issue with 5GHz PMP 450M’s on 20.2.1.

All SM’s were also on 20.2.1

We would have a handful of SM’s with a sounding state of “TRACKING” but the MU-MIMO Rate was “not eligible”. These SM’s were often stuck in a low modulation rate. This caused significant throughput issues when those SM’s downloaded data. We rolled back to 16.2.3.1 and the sounding states were all again as expected. Traffic flow returned to normal.

This did not seem to affect 450i AP’s.

A support ticket has been created

Well, that’s concerning, I’ve seen APs on all versions have failed tracking so no MU-MIMO but never tracked without mu-mimo has cambium said it’s a bug or anything?

Anyone else seeing it?

SM’s with really low modulation can’t participate in MU-MIMO and as such the AP transmits in sector mode. This can have a crippling effect on overall frame utilization of the AP… basically a few bad clients that talk a lot can bring an otherwise healthy AP to it’s knees. What we do is periodically audit our AP’s and try to fix or remove these bad apples.

1 Like

I thought when modulation was low the lack of MU-MIMO would also result in no tracking… at least thats how its exhibited in the past for me… do you mean you’ve seen low snr with tracking but no mu-mimo?

Typically, clients with poor modulation will not track and will not be able to participate in MU-MIMO… but I’ve also seen clients with great modulation that are tracking that cannot participate in MU-MIMO. Here’s an example AP with many nNLOS clients going through lots of pine trees:

Yes, throghput is instable… I’m back to R16
Tracking work better with R16

Thanks

I’m wondering if you are seeing a similar issue as we are. We see it in v16.x + v20.x where our some of our SM’s suddenly have a bad uplink power level. Usually a sudden 20dB swing. Re-registering the SM to the AP fixes the condition temporarily. Or it sometimes corrects itself. We already have an open ticket but troubleshooting has hit a wall.

I can’t say for certain as we don’t graph AP receive dBm. But, we don’t notice it while t/s.

Any chance those low AP receive levels happen at a time of low throughput? Does a linktest straighten them out?

Any chance those low AP receive levels happen at a time of low throughput? Does a linktest straighten them out?

No, this happens at any random part of the day. A link test does not correct the problem. Only forcing a re-reg (rescan, reboot SM, reboot AP) will correct it every time. Until it randomly happens again. Usually to the same SM’s.
It seems to happen more to connections that are a distance >2-3 miles away or who have a narrow LOS or fresnel zone clearance issue. Multiple 450m AP’s @ multiple sites.

Cambium is testing a fix for this on one of our 450m.

How is that going for you?

Much improved but they’ve said not quite how they want it so still in progress.

Anybody in Cambium (@Charlie ?) can confirm this issue?
Should we wait to upgrade?

Yeah we are looking at issue on a 450m AP with @Craig_Wass where the rate adapt isn’t 100% stable and performing as well as 16.2.3.1. We’ve found one fix that we will be getting into 20.3, but seems the rabbit hole goes deeper, so we are still investigating.

@Craig_Wass can maybe answer better as it caused him to roll back to 16.2.3.1, meanwhile there are thousands of radios running 20.2.1 or later. So I don’t have any critical concerns but there’s still issues we need to iron out with 20.X line.

1 Like

As we are discussing here, I’m wondering if your issues are coming from you still using BAM. We will discuss in the other thread, but you linked here so wanted to post in case others come here.

Hello @Charlie, we experienced similar issues and opened a case (269040) to the Support with logs and screenshots attached if you need more data to analize the problem.

What is the status on this. Should 450M AP’s be reverted back to 16.2.3.1 for better rate adapt?

Have you tried 20.2.2.1. Issues has been solved?

We have not. I’m under the impression this is addressed in 20.3. We’ll give that a try after a few days.

Any news about it?
Is this fixed in 20.3-B1? CPY-17365 maybe?

Thank you