I'm looking at the bottom of performance on my AP and see
Downlink Frame Time
|Total Frame Time Used
Uplink Frame Time
|Total Frame Time Used
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 :-)
just did a walk, the download is 184.108.40.206.4.1.177220.127.116.11.54 and upload is 18.104.22.168.4.1.17722.214.171.124.53
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 126.96.36.199.4.1.177188.8.131.52.51 and 184.108.40.206.4.1.177220.127.116.11.52 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.
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.