Re: RFC1155 Timeticks hitting maximum value

Hi-

I would anticipate that an intelligently designed NMS would watch for wrap
on a TimeTicks object by checking for an increment in snmpEngineBoots, or
alternatively, simply watch the value of the snmpEngineTime object, since
its granularity is seconds rather than 1/100th seconds yielding a 40k+ day
wrap interval.

In any case, the target system sure isn't running a MS OS ;-)

Regards,

Mark
--
http://EllisonSoftware.com/

On Wed, Jun 23, 2010 at 7:43 PM, Jon Saperia <[email protected]> wrote:

> But is was in the context specifically of hrSystemUptime - at least that is
> how I read it.  I was suggesting a surgical fix to a specific problem
> related to uptime.  That could be fixed with a single object and leave the
> others that use time ticks intact.
>
> That said, I do agree with you that a good NMS should be able to deal with
> this and other oddities in this and many other objects.
>
> /jon
> On Jun 23, 2010, at 7:30 PM, Randy Presuhn wrote:
>
> > Hi -
> >
> >> From: "Jon Saperia" <[email protected]>
> >> To: "Randy Presuhn" <[email protected]>
> >> Cc: <[email protected]>
> >> Sent: Wednesday, June 23, 2010 3:54 PM
> >> Subject: Re: [OPS-AREA] RFC1155 Timeticks hitting maximum value
> >>
> >> Why would a whole new set of objects be required to either fix,
> >> hrSystemUptime, or create a new higher capacity object?
> >
> > The question wasn't just about hrSystemUptime, but the fundamental
> > deficiency of time ticks.
> >
> > Coming up with a new time ticks syntax would effectively mean
> > every existing time ticks object would at least need to be
> > considered for obsolescence, and new objects would need
> > to be created in appropriate cases.  Counters currently referencing those
> > time ticks objects as discontinuity indicators would then have to be
> > considered for update as well, unless we were going to say that
> > implementations MUST support both representations.  (This quickly
> > becomes a replay of the 32-bit counter / 64-bit counter / paired-counter
> > discussion from SMIv2.)
> >
> > But that really wouldn't address the problem - an existing NMS
> > application that behaves badly when hrSystemUptime wraps.
> >
> > Randy
> >
> > _______________________________________________
> > OPS-AREA mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/ops-area
> >
>
> _______________________________________________
> OPS-AREA mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ops-area
>

_______________________________________________
OPS-AREA mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ops-area