Subject: Re: CVS commit: src/sbin/ifconfig
To: John Nemeth <jnemeth@victoria.tc.ca>
From: Bill Studenmund <wrstuden@netbsd.org>
List: tech-misc
Date: 04/23/2003 09:36:29
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.

> } 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.

> } 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.

Take care,

Bill