hi boneyard
let me try to answer some of your questions around the processorLoad OIDs and then the wlsxSysExtCpuUsedPercent OID.
For the processorLoad OIDs, here is a sample from my lab 620 while running a backup flash just to make it busy and show some significant value.
root@bt:/home/mibs# snmpwalk -v2c -mALL -M./6.1.3.0 -c public c620 1.3.6.1.4.1.14823.2.2.1.2.1.13
WLSX-SYSTEMEXT-MIB::sysExtProcessorDescr.1 = STRING: Supervisor Card CPU
WLSX-SYSTEMEXT-MIB::sysExtProcessorDescr.2 = STRING: Network Processor CPU2
WLSX-SYSTEMEXT-MIB::sysExtProcessorDescr.3 = STRING: Network Processor CPU3
WLSX-SYSTEMEXT-MIB::sysExtProcessorLoad.1 = INTEGER: 60
WLSX-SYSTEMEXT-MIB::sysExtProcessorLoad.2 = INTEGER: 0
WLSX-SYSTEMEXT-MIB::sysExtProcessorLoad.3 = INTEGER: 0
Let's address the network processor (a.k.a. NPU) OIDs first. These correspond to the number of CPU cores being used for the datapath which essentially means user traffic processing. You can review the utilisation of these NPUs via the CLI command show datapath utilization. The number of CPU cores used for datapath varies based on platform, as you see above for my lab 620 there are just 2 cores being used, however in your 650 you see 5 cores. In a 3600 as a final example, you will find 24 cores allocated to NPU.
The Supervisor Card CPU (SC CPU) is an aggregate of the remaining cores which are dedicated to running ArubaOS. Note that the naming is based on the legacy SC1 chassis based "supervisor cards". In the case of the example above, the NPU's start at CPU2, hence cpu 0+1 are being used for SC CPU. In the case of your lab 650 you can see there are 4 cores (0~3) being used and again for the 3600 as a final example, you would see 8 cores assigned to SC CPU.
As such, when you display that single value OID (and even the show cpuload cli command) a number of CPUs are being represented. Here is the show cpuload (equivalent) taken during that time where I was running backup flash to drive up the CPU:
Cpu(s): 50.6%us, 3.5%sy, 0.0%ni, 45.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
The numbers don't exactly match since the SNMP OID is a 60 second average and the output of the command which I took that cpuload from updates every 5 seconds. However, the point here is that the numbers do approximately match and are an accurate representation of the overall load across all CPU cores that are considered SC CPU cores.
Let's consider the same 620 allowed to become idle (removing the NPUs from output):
root@bt:~# snmpwalk -v2c -mALL -M./6.1.3.0 -c public c620 1.3.6.1.4.1.14823.2.2.1.2.1.13
iso.3.6.1.4.1.14823.2.2.1.2.1.13.1.2.1 = STRING: "Supervisor Card CPU"
iso.3.6.1.4.1.14823.2.2.1.2.1.13.1.3.1 = INTEGER: 1
root@bt:~#
(sg-620) #show cpuload
user 0.7%, system 0.7%, idle 98.7%
(sg-620) #
both outputs are showing around 1% load (occasionally the rounding to integer sends the SNMP value back to 0%, but it generally shows 1% for idle)
With regards to wlsxSysExtCpuUsedPercent - the value is meant to be determined as such:
wlsxSysExtCpuUsedPercent = 100 - cpu_idle
where cpu_idle is the idle % value as shown in output of show cpuload (which is updated every 10 seconds)
I am not sure if there is a bug with this OID, it's implementation seems quite straightforward - can you try to monitor the value of the SNMP OID compared to the show cpuload output wihin a couple of seconds of each other ?
regards
-jeff