[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: snmpconf PM MIB issue #6 CLOSED - counter32Delta and counterRate
I'm not talking about counter wraps -- I'm talking
about discontinuities as they're defined in SMI.
Back in the beginning (actually before I became
involved with SNMP, so somebody can correct me if
I'm getting this wrong), the only discontinuity
event recognized for a counter was reset of the
SNMP agent. So a manager was supposed to retrieve
sysUpTime along with counter values, and determine
that there had not been an agent reset before
doing a delta calculation.
Later, it was realized that counters could undergo
discontinuities even when the entire SNMP agent
did not have a reset. Examples include subagent
reset, resource reconfiguration, and resource
deactivation/reactivation. So additional objects
were added to MIBs, to store the time at which a
specific counter or set of counters last
experienced a discontinuity. Managers are
supposed to check these discontinuity objects
(as well as sysUpTime) before doing a delta
calculation. I'm just looking for some similar
validation, before a script does a delta
calculation, that the resulting delta value will
Advanced Design and Technology
Application Integration Middleware Division
IBM Software Group
David Partain <David.Partain@ericsson.com>@snmp.com on 05/17/2001 08:24:07
Please respond to firstname.lastname@example.org
Sent by: email@example.com
Subject: Re: snmpconf PM MIB issue #6 CLOSED - counter32Delta and
dp> Issue: When Steve presented counter32Delta and counterRate,
dp> there was a fair bit of discussion on whether they were right
dp> as they are. More thought and discussion is required.
dp> There have been no discussion and no questions. As such,
dp> I assume that everyone understands how these two accessor
dp> functions work and that the description is clear.
dp> If you have questions, please bring them up quickly.
and Bob Moore did:
bm> I'm still uneasy about counter discontinuity indicators
bm> and how they figure into this topic. The purpose of a
bm> discontinuity indicator is to raise a flag that says
bm> "Don't do a delta calculation for this counter - the
bm> result will be invalid!" Since these accessor functions
bm> don't themselves do anything with discontinuity indicators
bm> (and it's hard to see how they could, since that would
bm> require MIB knowledge), it must be up to the script writer
bm> to check them before invoking these functions.
I'm not sure what I'm missing... In the definition of
counterRate, there is the following text:
The delta calculation will allow for 32-bit counter semantics
if it encounters rollover between the two retrievals unless
the optional argument '64bit' is present and equal to 1,
in which case it will allow for 64-bit counter semantics.
That looks to me like the policy engine _will_ keep track of
the rollover and provide a correct delta. Furthermore,
counter32Delta is specifically to retrieve the delta of
two numbers while taking 32-bit rollover into account.
bm> If this is
bm> how it's supposed to work, then the document should have
bm> examples where the calls to these functions are preceded
bm> by statements that check (and save) the appropriate
bm> discontinuity indicator.
There is only one example, under counter32Delta(). It
doesn't look at a discontinuity indicator, since this
doesn't exist as I see it.
Can you help me understand the scenarios that you think
something more might be needed?
bm> I know this moves the scripts in the direction of larger
bm> and uglier, but given the way counters are defined in SMI,
bm> I don't see any other way to do it.
With kind regards,
David Partain David.Partain@ericsson.com
Ericsson Radio Systems AB Tel: +46 13 28 41 44
Research and Innovation Fax: +46 13 28 75 67
P.O. Box 1248
SE-581 12 Linköping, Sweden