SNMP OID for Total Frame Time Used %

I'm looking at the bottom of performance on my AP and see

Downlink Frame Time
Total Frame Time Used 15.1%
Uplink Frame Time
Total Frame Time Used 100%

I would love to graph these two values with SNMP.  With the release of 2.5.1 I was hoping to this OID added, but I certainly don't see it.

Can anyone tell me why the uplink frame time is (seemingly) always 100%?

The 100% frame utilization stat is a bug... I believe they're fixing it in the next release... as to the OID for these two values, I'd love to know as well :-)

1 Like

just did a walk, the download is  and upload is

1 Like

 well crap sorry guys,   

those numbers are the total number of frames used per second,  you'd need to do some math in order to figure your %%%%     or if your software can do some math and use fields and with them, you can figure your percentage....      or monitor both and realize when 53 and 54 get near 51 and 52 your frames are getting filled.... not exactly the same, but can give you some idea until that specific MIB is available 


When will we have the frame time percentages available via SNMP?  This is a very handy number to monitor, and it's already available on PMP450.


1 Like

Same problem. It would be nice to have the percentage of frame utilization, like PMP450.

I agree that having a single OID for each uplink and downlink to represent the frame utilization would be helpful.

I also agree this would be a very useful stat to graph. I would also love it to be available in cnMaestro like the 450 is.

Looking at these OIDs more closely...These are 1-second period results.

I believe the PMP450 has 1-, 5-, and 15-minute period OIDs to poll the frame utilization percentages. I would like to see those periods in ePMP as well whenif frame utilization percentage is ever implemented in SNMP.

I would expect to see downlink % utilization available on an SNMP OID pretty soon, like majorly soon.

Oh, I just realized these frame usage OIDs are being returned as Counter32 instead of Integer, UInteger32 or Guage32. This is a very bad decision.

Counters go up over time and never go down, so any rrd-backed application is going to assume any time a sample is smaller than the prior, that the "counter" rolled over and will spoil the visualization of the data.