On Aug 8,  9:43pm, Bill Studenmund wrote:
} On Wed, 23 Apr 2003, John Nemeth wrote:
} > On Aug 9,  1:43am, Havard Eidnes wrote:
} > }
} > } >      The way I handle it in my scripts is to poll the device every
} > } > five minutes.  If a counter value is less then the preceeding
} > } > counter value, then I check to see if the preceeding value was
} > } > within approximately 200,000,000 of the wrap point then I assumed
} > } > that it wrapped; otherwise, I assume that it was reset.
} > }
} > } This builds an assumption into the post-processor of the polling data
} > } which only works as long as the data rate for the interface is modest.
} > } You'd only need to have a data rate of a little over 5.3Mbit/s for the
} > } assumption above to miss data on a counter wrap (200,000,000 bytes in
} >
} >      No data is missed on a counter wrap.
} 
} At a 5 minute polling, yes they are. SNMP guarantees that you won't get
} more than one wrap using 1 minute polls; if something could wrap more
} than once, you have to use a 64-bit counter. By using 5 minute polls,
} you're relaxing that restriction, and you could get multiple wraps & not
} know it. Since you don't know how many wraps there are, you can develop an
} anser that may be missing a few multiples of 2^32.

     This won't happen in my case.  However, if needed, it would be
simple for me to increase the polling frequency.

     I'd love to have 64 bit counters.  Then I wouldn't have to worry
about wraps at all, just resets.

} > } 5 minutes is only about 5.3Mbit/s).  Also remember that a 32-bit octet
} > } counter will wrap in 5 minutes at approximately 114.5Mbit/s.  I think
} >
} >      Kind of hard to do on a 10Mb interface.
} 
} But easy on a Gigabit Ethernet and a 10 Gigabit interface. We have GigE
} cards supported in NetBSD, and many of us use them daily. While 10 Gig
} isn't out yet, it is real enough that we know we'll have it in a few
} years.

     I don't have any and I'm not likely to have any, any time soon.
However, as noted above, I can simply increase the polling frequency if
needed.  I may need to do some work on the post processor in order to
handle 64 bit counters, though.

} > } that building in assumptions about the expected data rate in a general
} > } SNMP data post-processor is bad.  Instead, the SNMP agent should
} >
} >      Not exactly general.  It was built for my specific needs.  The
} > polling data is kept for the current month and the previous month, so
} > if there is a problem, I can always reprocess it.  Also, it can be
} > tweaked by changing the polling frequency or the trigger value.
} 
} Then for your uses, that sounds fine. But we need to come up with
} something that'll work well for everyone.

     I'm not sure why my methods couldn't be generalised by polling
every minute, making sure it can handle 64 bit counters, checking
sysuptime when it sees a lower value, and adding some smarts to
automatically adjust the trigger value (and possibly the frequency).

}-- End of excerpt from Bill Studenmund