Any update on this, Cambium? We are hearing many more complaints about this after the 16.2.2 release. We are seeing it on APs that are not crowded (under 20 customers) so it shouldn’t be the MIR at capacity bug in the release notes that hasn’t been fixed.
So in the original thread, the OP found that his link tests were much higher then his actual speed tests behind the SM. The reason for this was… 1. when you run a link tests between AP and SM, it temporally stops all traffic across the AP, and gives you the best possible result. 2. when he’d run speed tests behind the client, they were lower, because the group that the SM he was testing in was saturated. 3. He resolved the problem by adding an AP offset from the original one, and migrating clients over to the new AP, thus reducing load on the original AP/group.
If you do not have an optimal spread of clients across all 7 groups in 90deg’s and/or you have many top talkers falling into one group, then it does not make sense to deploy 450m. It would make more sense to deploy something like one or two 450i w/30deg horn antenna.
No, because it was about two months ago when we upgraded all the APs to 16.2.2, so there is no historical data for comparison. Before 16.2.2 we had no complaints with this issue. Now after upgrading we are receiving complaints about this regularly, even with 16.2.3.
MIR without bridging shows high throughput, MIR with bridging is set it will be way below the cap on the radius server. This is happening on low count APs now (under 20 SMs). I recall having this issue previously in one of the pre 16.1 releases. Then it was fixed in 16.1 and now it is back. This is happening on 450i as well as 450M.
Ok I do have one question before opening a support ticket.
If there is no longer an MIR cap in radius and the MIR on the SM is the default of 150Mbps, should “Link Test with Bridging and MIR” return similar test results as “Link Test with Bridging”, assuming the speeds do not near the 150Mbps default SM cap?
Hi, We are experiencing exactly the same error as you describe, with 16.2.2? And we only have 10 customers on AP! When the load of 450m exceeds 60-80Mbits, 450m is unable to deliver the given speed to customers, but if we measure speed between AP and SM, we get given speed
What are your values for your Downlink and Uplink Burst Allocations? These values are in kilobits not kilobits-per-second. If these are at 0, then you will see lower values on the MIR with bridging test. As a rule-of-thumb, you can try 2X the MIR Downlink and Uplink Data Rate values. For example, if you have MIR Downlink Data Rate set to 15000 kbps, then set a Downlink Burst Allocation of 30000 kbits. This tends to get the MIR to run at the expected max (assuming your Max Burst Data rates are set to 0).
Here is what we set to burst. Problem is we now tried this without MIR in radius and are still having issues. We have a ticket open with Cambium and sent multiple engineering files. Hopefully someone at Cambium can look at it soon because we are getting more and more complaints. The installers have noticed more issues with speeds since the 16.1 release or so. Before that speeds were great, now we get a lot more complaints from customers.