2009/1/13 Mohr James <[email protected]>:
> From what I have found, it appears that net-snmp 5.4.1 is writing to
> UCD-SNMP-MIB::ssCpuIdle. According to the MIB file, this one of several
> OIDs that were deprecated several years ago in favor of the "raw"
> values.
The problem with this MIB object (and the other "cooked" values) was twofold:
- firstly, they were underspecfied when first defined
- secondly, they did not conform to good MIB design practice
These particular objects provide an "average" of the value being monitored,
calculated over a fixed time period. As such, they are less flexible than
the equivalent raw counters, which can be used to generate similar averages
over an arbitrary time period (by polling twice and taking the differences).
Such raw counters are the accepted way of defining MIB objects to monitor
this type of metric. Hence, these objects do not conform to good MIB design.
In addition, the original MIB definitions didn't specify what this fixed time
period should be. And when the code was written to implemented them on
a variety of different operating systems, the coders had different ideas
as to what the period should be.
This resulted in inconsistent results when querying the same MIB
object on different systems.
> When I create CPU activity (find /), the value of
> UCD-SNMP-MIB::ssCpuIdle changes. So it would seem that this value is
> still being written to.
> However, if it is deprecated, why is it still being used?
To address these problems, we introduced the raw counter objects
(being the Right Way To Do This), and deprecated the original averages.
But we didn't remove the objects completely, because we knew there would
be people who were using these values to actively monitor their systems.
>From a purist point of view, these objects were fundamentally broken,
and should have be removed. But pragmatically, individual administrators
were using them to solve real-world problems, and probably didn't care
about the technical deficiencies.
But they *would* care (and complain) if these objects disappeared
and all of their scripts broke. It was easier for us, and better for the
Net-SNMP community, to leave these objects working.
Some time later, the code to supply the raw data was significantly
re-written, and it became straightforward to provide a consistent
implementation of the average objects. At that point, the MIB definitions
were clarified and updated, to agree on an explicit fixed time period (60s)
for calculating the averages.
> Another machine has net-snmp 5.2.1. I create the same CPU activity
> and snmpget does not indicate any change.
What you are probably seeing is the difference between a 1-minute average
(which will change noticeably over a short period of monitoring) and a
lifetime average (which won't).
> So it is even more confusing
Indeed - see the comments above about inconsistent implementations.
> and seems as if this functionality has been re-added.
It's not that it has been removed and re-added.
Rather that it has recently been implemented consistently,
using a sensible time period. (A lifetime average was of no
practical use to the administrator!)
I hope this serves to explain the history behind these objects.
Dave
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
