With this setting enabled the contention slots setting seems to still be exposed. Does the value simply no longer matter or what should it be set at?
If I wanted to enable "Auto Contention" on all my APs is there a bulk wat to do this with cnMaestro?
Are there any counters that will tell me I am running out of contention slots?
We love the new auto contention slot feature and have enabled it on all of our 450 and 450i AP's. Note that this feature isn't available for 450m AP's yet, and will be available in a later release.
Enabling auto contention slots renders the contentions slot value irrelevant. EDIT: Even with auto contention enabled, you still should make sure that your contention slot value is correctly set across AP's and sites that share sync.
You can create a JSON-based config script in cnMaestro and push it out to all your AP's. Here's the script we use:
I've also included a text file with this so you can just copy and paste.
You can find some stats to watch under the AP's Statistics -> Frame Utilization -> Uplink Counts section.
Is there an snmp command to enable it?
@hci wrote:
Is there an snmp command to enable it?
Yes. In whispApsConfig MIB, OID autoContention, number 260.
@hci wrote:With this setting enabled the contention slots setting seems to still be exposed. Does the value simply no longer matter or what should it be set at?
The Contention Slots setting still matters for your transmit/receive timing for the downlink/uplink percentage and switchover time, whether AutoContention is enabled or disabled. So if you are going to switch Contention Slots setting make sure you run the Frame Calculator tool to make sure your Tx/Rx time aren't over lapping with any other APs.
Are there any counters that will tell me I am running out of contention slots?
The simple answer to this tough question is uplink throughput should be better with AutoContention enabled versus disabled. (Unless you have the exact right amount of Contention Slots configured.) :) AutoContention is most valuable for sectors with high numbers of SMs that before had to set a high number of contention slots to keep the latency down. Now with AutoContention both throughput and latency are balanced based upon the load from the SMs.
But if your uplink wasn't every hitting 100% Frame Utilization it will be even harder to tell the difference between the two settings.
@Charlie wrote:
@hci wrote:With this setting enabled the contention slots setting seems to still be exposed. Does the value simply no longer matter or what should it be set at?
The Contention Slots setting still matters for your transmit/receive timing for the downlink/uplink percentage and switchover time, whether AutoContention is enabled or disabled. So if you are going to switch Contention Slots setting make sure you run the Frame Calculator tool to make sure your Tx/Rx time aren't over lapping with any other APs.
@Charlie WOW, really? I had no idea that these had to be set correctly. After multiple talks about auto contention with Cambium engineers, troubleshooting it, working on beta, etc. this was never mentioned to me and I was lead to believe that this setting was no longer used. Time to audit all our AP's contention slot numbers I guess :-/
@Eric Ozrelic wrote:
@Charlie wrote:
@hci wrote:With this setting enabled the contention slots setting seems to still be exposed. Does the value simply no longer matter or what should it be set at?
The Contention Slots setting still matters for your transmit/receive timing for the downlink/uplink percentage and switchover time, whether AutoContention is enabled or disabled. So if you are going to switch Contention Slots setting make sure you run the Frame Calculator tool to make sure your Tx/Rx time aren't over lapping with any other APs.
@Charlie WOW, really? I had no idea that these had to be set correctly. After multiple talks about auto contention with Cambium engineers, troubleshooting it, working on beta, etc. this was never mentioned to me and I was lead to believe that this setting was no longer used. Time to audit all our AP's contention slot numbers I guess :-/
Eric, yes, really. :-/
If we had no longer used the Contention Slots configuration to calculation the downlink/uplink transition, then enabling/disabling this setting on one AP on a single AP could cause self interference issues with the other APs that were already aligned. So we decided it was best to leave the Frame Configuration the same whether the setting is enabled or disabled, especially because there is no reboot required to enable/disable AutoContention.
You're right that it isn't used in the implementation of AutoContention, but the setting still affects how many uplink slots are configured.
As long as you did the same thing on all your APs, hopefully you should be fine. Sorry if we did not make this clear enough. The whole point to AutoContention is it doesn't matter what you have Contention Slots set to, it will do it's best. Except it absolutely does matter for Frame Configuration, so just leave alone unless you are ready to change for all your APs at that site.
So it doesn't have to be "correctly" (as there is no "correct" with AutoContention enabled) just whatever you want it for downlink/uplink percentage.
So it would make sense to set contentions slots to 1 and enable auto contention slot on all APs? If more then 1 is needed the auto setting will take care of it?
@hci wrote:So it would make sense to set contentions slots to 1 and enable auto contention slot on all APs? If more then 1 is needed the auto setting will take care of it?
Yep...we recently did this with all of our AP's.
I am trying to figure out how to set contention slots with SNMP but having issues.
# snmpget -v2c -c Canopy -m ALL x.x.x.x .1.3.6.1.4.1.161.19.10.1.1.4.0
SNMPv2-SMI::enterprises.161.19.10.1.1.4.0 = No Such Object available on this agent at this OID
This seems to work fine for checking and changing auto contention:
snmpget -v2c -c Canopy -m ALL x.x.x.x .1.3.6.1.4.1.161.19.3.1.1.260.0
SNMPv2-SMI::enterprises.161.19.3.1.1.260.0 = INTEGER: 0
What am I doing wrong here?
numCtlSlotsHW Object ID: 1.3.6.1.4.1.161.19.3.1.1.42 Syntax: INTEGER Access: read-write Status: deprecated This attribute is deprecated. Please see radioControlSlots.
Used this instead since I could not get radioControlSlots to work.
I don't see an "Auto Contention" setting on our 450m APs. Why is that?
@hci wrote:I don't see an "Auto Contention" setting on our 450m APs. Why is that?
The feature was delayed on 450m due to some technical difficulties. It will be available in the next released, 16.2.
Any ETA on 16.2 non-beta?
Hi,
This feature is being delayed further. Due to the vastly different nature of Massive MU-MIMO in relation to SU-MIMO (single user, sector mode) operation of Canopy, the operation of contention slots is considerably different. With normal SU-MIMO Canopy on 450i and 450 APs, there is a single frame and the contention slots are shared by every subscriber in the sector, and so it was a bit more straightforward to develop the algorithms to automatically adjust contention slot count based on sector performance.
With MU-MIMO operation, each frame can present a different combination and thus a different contention slot scenario. And trying to fit the algorithms developed for SU-MIMO 450i/450 into 450m actually caused adverse effects on 450m MU-MIMO while not actually solving any issue. So, we have taken a step back to reassess the issue and this means that it will not be in 16.2 or the following release.
That being said, we also do not think there is as big of a contention slot issue in MU-MIMO as there was in SU-MIMO, so not having the feature should not be seen as a big impact to optimization. The biggest benefit will be simplifying the configuration (you wont have to set/guess at the value) as well as possibly improving some latencies in some certain cases of overloaded spatial frequencies. We do see the value in the feature on the whole, but we need to do it properly for MU-MIMO so that it doesn't cause more problems than it solves.
Aaron,
For now we have set everything on 1 slot even 450m's. The 450m's we have deployed are not yet heavilly loaded mainly to help with noise. Do think there will be issue with one control slot on the 450m?
Thanks.
We have our all our APs set to one contention slot. On 450i APs auto contention is enabled. On a couple 450m APs in same cluster contention slots is set to one and auto contention is not available. I just noticed that since turning up the 450m APs the 450i frame utilization shot up. Is this a colocation issue with auto contention?
@hci wrote:We have our all our APs set to one contention slot. On 450i APs auto contention is enabled. On a couple 450m APs in same cluster contention slots is set to one and auto contention is not available. I just noticed that since turning up the 450m APs the 450i frame utilization shot up. Is this a colocation issue with auto contention?
We've used both auto and non auto AP's around each other without noticing any issues. Are all the rest of the sync-specific settings the same? Have you tried turning off auto-contention on one of the 450i's that's having issues to see if the problems go away?
@hci wrote:We have our all our APs set to one contention slot. On 450i APs auto contention is enabled. On a couple 450m APs in same cluster contention slots is set to one and auto contention is not available. I just noticed that since turning up the 450m APs the 450i frame utilization shot up. Is this a colocation issue with auto contention?
hci,
Enabling Auto Contention does not change your downlink/uplink transition time. So if enabling Auto Contention, the "Contention Slots" parameter then is only used for the Frame Calculation. This is to ensure upgrade/downgrade compatibility. Otherwise, if you just upgrade one AP it can throw off the timing of your sector.
Each radio should have the Frame Calculator tool run on it to make sure that you're colocating properly, which means your AP's Transmit End Times are not over lapping with another AP's Receive Start Time. Note that the Auto Contention parameter is not included in the Frame Calculator tool, as it doesn't impact the frame directly.
You're welcome to post your settings here and I can help you check them. Settings that impact the frame: