Monitoring Utilization 450m 15.1.1

I found the following post relating to utilization but I do not think it necessarily speaks to what I need.

Additional MU-MIMO statistics

For my 450 APs I have have used 5m Radio Uplink and Downlink utilzation to determine if my radios were loaded or not (.1.3.6.1.4.1.161.19.3.1.12.2.2.0 and .1.3.6.1.4.1.161.19.3.1.12.2.1.0) and was told that it was not accurate for the Medusa radios. I think it was mentioned (I cannot find it) in another post that they were going to address this in 15.1.1.

My question is, for a general look at the radio utilization (I am not concerned about distribution as I do not have much control of that), what oid should I use or combination of oids should I use to calculate an accurate utilization?

Hi,

To start off with, instead of DL utilisation I would use ‚ÄėSector Utilisation‚Äô :

frUtlMedMumimoDownlinkSectorUtilization  

.1.3.6.1.4.1.161.19.3.1.12.2.29

This covers both SU and MU-MIMO traffic ‚Äď if this hits 100% the sector has maxed out.

To get the ratio of SU and MU-MIMO traffic (if you were interested) you could also monitor

frUtlMedMumimoDownlinkSumimoUtilization

.1.3.6.1.4.1.161.19.3.1.12.2.31

frUtlMedMumimoDownlinkMumimoUtilization

.1.3.6.1.4.1.161.19.3.1.12.2.30

The UL utilisation OID is probably OK to use for now. We are going to introduce uplink MU-MIMO in a future release at which time there will be a new stat to look at.

Hopefully that gets you started with some useful monitoring.

Regards,

Andy.

Hello,

We've run into an interesting case... so you state to use .1.3.6.1.4.1.161.19.3.1.12.2.29 for sector utilization.

When I poll one of my medusa using:

snmpwalk -v 2c -c public ap-name-here .1.3.6.1.4.1.161.19.3.1.12.2.29

I get:

SNMPv2-SMI::enterprises.161.19.3.1.12.2.29.0 = INTEGER: 59

When I look at the web interface however 

Sector Utilization: 61%

One of our devs figured out if you average  a walk of the OID .1.3.6.1.4.1.161.19.3.1.12.4.1.6 you get what the UI seems to be reporting.

Tim

Thanks Tim,

I was taking the OIDs from the release notes. I'll get someone to check them.

Andy.

1 Like

Hi Tim,

Can you confirm that your Statistics Display Interval was is to 5 min on the Frame Utilization page.  The OID you cite reflects the 5 minute interval.  In the meantime, I will investigate.

EDIT: OID .1.3.6.1.4.1.161.19.3.1.12.4.1.6 actually reflects the 1 minute (Low) interval setting.  So I suspect that your Display Interval is  set to 1 minute.  Please confirm at your earliest convenience.

Thanks,

Anthony

1 Like

Hi all,

am I wrong if I say the equivalent to

frUtlMedMumimoDownlinkSectorUtilization .1.3.6.1.4.1.161.19.3.1.12.2.29.0 (5m polling)

but with 1m sampling, is:

frUtlLowMumimoDownlinkSectorUtilization .1.3.6.1.4.1.161.19.3.1.12.1.29.0 ?

I think .1.3.6.1.4.1.161.19.3.1.12.4.1.6.[1...32] is frUtlLowTotalMumimoDownlinkUtilization and these a slight different thing (an array of different samples?)

Kind regards

Rocco

Hello Rocco,

You are right, I think. The names of these elements are structured: those which 

include the word "Low" refer to one minute averages; "Med" refers to five minute 

averages and "High" refers to fifteen minute averages. You can find the related 

OIDs like this - if you have the appropriate tools installed:

[64]% snmptranslate -m WHISP-APS-MIB -M +/home/stu001/work/medusa/bld/canopy/MIB/ -IR -Tso | paste - - | column -t | grep MumimoDownlinkSectorUtilization
.1.3.6.1.4.1.161.19.3.1.12.1.29    .iso.org.dod.internet.private.enterprises.mot.whispRoot.whispProducts.whispAps.whispApsFrUtlStats.whispApsFrUtlStatsIntervalLow.frUtlLowMumimoDownlinkSectorUtilization
.1.3.6.1.4.1.161.19.3.1.12.2.29    .iso.org.dod.internet.private.enterprises.mot.whispRoot.whispProducts.whispAps.whispApsFrUtlStats.whispApsFrUtlStatsIntervalMedium.frUtlMedMumimoDownlinkSectorUtilization
.1.3.6.1.4.1.161.19.3.1.12.3.29    .iso.org.dod.internet.private.enterprises.mot.whispRoot.whispProducts.whispAps.whispApsFrUtlStats.whispApsFrUtlStatsIntervalHigh.frUtlHighMumimoDownlinkSectorUtilization

The other OID you mention .1.3.6.1.4.1.161.19.3.1.12.4.1.6.[1...32] relate to the Spatial Utilization shown 

in the MU-MIMO Downlink Utilisation section of the Frame Utilization tab in the GUI. These are also 

available for different averaging intervals:

[67]% snmptranslate -m WHISP-APS-MIB -M +/home/stu001/work/medusa/bld/canopy/MIB/ -IR -Tso | paste - - | column -t | grep frUtl.*TotalMumimoDownlinkUtilization
.1.3.6.1.4.1.161.19.3.1.12.4.1.6   .iso.org.dod.internet.private.enterprises.mot.whispRoot.whispProducts.whispAps.whispApsFrUtlStats.whispApsFrUtlStatsMumimoSpatialTable.whispApsFrUtlStatsMumimoSpatialEntry.frUtlLowTotalMumimoDownlinkUtilization
.1.3.6.1.4.1.161.19.3.1.12.4.1.7   .iso.org.dod.internet.private.enterprises.mot.whispRoot.whispProducts.whispAps.whispApsFrUtlStats.whispApsFrUtlStatsMumimoSpatialTable.whispApsFrUtlStatsMumimoSpatialEntry.frUtlMedTotalMumimoDownlinkUtilization
.1.3.6.1.4.1.161.19.3.1.12.4.1.8   .iso.org.dod.internet.private.enterprises.mot.whispRoot.whispProducts.whispAps.whispApsFrUtlStats.whispApsFrUtlStatsMumimoSpatialTable.whispApsFrUtlStatsMumimoSpatialEntry.frUtlHighTotalMumimoDownlinkUtilization

These are arrays describing the utilisation in ranges of spatial frequency - just like the tables in the GUI.

The post referred to at the top of this thread provides some more detail about these spatial

frequency metrics.

Best regards,

simon

1 Like

Hi Simon,

I actually used a MIB browser of course.

Thank you for your confirmation.

Rocco

Hi all,

after a few weeks we are inspecting graphs built on top of the OID suggested.

On a AP with 108 SMs authenticated (with some of them in bridge configuration with multiple users for about 170 pppoe customers) here are our results.

We observe a bit confusing thing: it never goes over 60-70% (it seems capped) and it's the same for several different throughputs and channel usages.

The bandwith availability is good even in peak hours from the speed tests we receive as feedback from customers (and throughput graph is not capped, confirming that).

As you can see the OID for the capacity value is high from the 8am , traffic increases during the day but the capacity doesn't reflect this.

Is this kind of behaviour the same for all of you using 450m APs?

@Cambium: can you elaborate on this?

Thank you and kind regards

Rocco

1 Like

Hi Rocco,

Thanks for the update, always great to get more results from the field.

If the sector utilisation was really ‚Äėcapped‚Äô I would expect both that and your throughput graphs to have a flattening at the top. We don‚Äôt see this and the system seems to meet the peak demand.

To explain the rise early in the morning sector utilisation, without any subsequent increase in the day despite the increase in throughput, I propose the following may happen.

During the night there is just the slow background traffic mainly covered by SU-MIMO. In the morning as a few more users come on line there is more demand, which will initially be met by SU-MIMO (this will increase the sector Utilisation). During the day as more load is placed on the AP it will switch over to using MU-MIMO groups more and more often. This may actually decrease the sector utilisation figure as the MU-MIMO operation is so much more efficient than the SU-MIMO it is replacing. This leads to the, not immediately obvious, conclusion that the sector utilisation can be lower during the peak throughput times (e.g. 8 or 9PM in your data).  I think you still have a significant overhead available on this sector.

If you also managed to collect the SU-MIMO utilisation and MU-MIMO utilisation then we could corroborate this.

frUtlMedMumimoDownlinkSumimoUtilization

.1.3.6.1.4.1.161.19.3.1.12.2.31

frUtlMedMumimoDownlinkMumimoUtilization

.1.3.6.1.4.1.161.19.3.1.12.2.30

You could also look at the MU-MIMO multiplexing gain, which should increase to a peak in the busy time.

frUtlMedMumimoDownlinkMultiplexingGain

.1.3.6.1.4.1.161.19.3.1.12.2.32

Finally, you could also collect your original 450 DL frame utilisation for comparison ‚Äď as that is where this thread started. This should confirm the MU-MIMO usage increasing as the frame utilisation gets large (the frame utilisation may seem to plateau but the actual throughput and sector utilisation should not).

Thanks again for taking the time to share some real world performance data with the community.

Kind Regards,

Andy.

1 Like

Rocco - If you're willing to, we'd love to hear additional feedback if you implement the suggestions that Andy has put forth.  Thanks.

Hi Rocco,

Have you had a chance to collect the stats I suggested yet ?

Also if Rocco, or any other users, out there want to make any suggestions for how to make the MU-MIMO statistics more user friendly or just more useful for customers please do let us know.

Andrew.

I find it confusing when comparing single to multi user Mimo statistics, as the AP is always switching based on usage.

I think it’d be more straightforward to lock the AP into MU-MIMO more, if only for understanding a day’s worth of data.

What would be the disadvantages of doing this?

You can't really "lock" it into a specific mode, because there are parts of the frame where the AP will operate on a sector basis (such as when the SMs are sending requests, or high priority channels are being serviced).

What questions are you trying to answer?  "How full is my sector?" Something else?

Yes, we're just trying to get a sense of reserve capacity.

I am now tracking a few of the oids and things are making more sense. 

One question though, is sector utilization somewhat linear and predictable in relation to throughput? Let's assume that there is little to no SU-MIMO, and the 450m is doing all MU-MIMO. Does the 450m use the least amount of groups needed at that moment, or will it scale up groups as needed for capacity? If it does scale up groups, then I guess the sector capacity would not be linear.

Hi Kelmore,

There is a graph in the thread 'Anyone managed to max out a 450m' on page one.
In this case the relationship between throughput and MUMIMO utilization was pretty linear, Sector Utilization would have followed the MUMIMO in this case.
However this was a lab test where we could form groups of 7 every frame (different set of 7 each frame as we were servicing 21 VCs)

Real world results will probably be more noisy.
In forming a group the 450m looks at the amount of data waiting to be sent to each SM and combines this with all the grouping possiblities (based on spatial frequency (azimuth)) to get the optimum boost to sector throughput.
The group formed will likely be different every frame (2.5ms or 5ms, current s/w forms one group per frame, but up to 4 groups per frame will be coming soon giving another boost to DL performance)
There will be thousands of possible groups for a typical sector. As the throughput increases the group SIZE will increase.

One other method to get a feel for reserve capacity would be to run the 'Link Capacity Test to Multiple VCs'.
This test puts data in the queues to all VCs and then tries to service all VCs in a fair manner.

I will see if we have any graphs, or can produce some, that show how the Throughput vs Utilization %s may work.
There is likely to be variation seen on different sector topologies and VC demand scenarios though.

best regards,
Andy.