Hi,
Talking about MIB II etc, where can I find information on these definitions
and how to use SNMP with its variables? I mean all there is to know about
SNMP!!

Thanks in advance

Dzilo


"Luong, David" <[EMAIL PROTECTED]> wrote:
Thank-you John for the clear explaination. I think I got confused when the
book stated "MIB II variables are stored as counters, you must take two poll
cycles...". Two? why two? But now I know that is just a minimum to get a
rate calculation..not a value that u MUST use.

-----Original Message-----
From: John Neiberger [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 02, 2001 10:17 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: utilization rate calculation


You can poll it as often as you feel like.  Look at it like this, we'll
use a car as an example.  Let's say you want to know how fast a car is
going and the only tools you have available are a stopwatch and the
odometer on the car.  The speedometer is broken.

If you only look at the odometer once and it says "100", does that tell
you anything about the speed of the car?  Nope.  However, if you look at
the odometer again after one minute and it says "102" then you know two
things:  1) the car has gone two miles in one minute and hence is going
120 miles per hour, and 2) the driver should lose his license.  (No
offense Dave, I know you'll read this!)

The same principle holds for MIB counters.  The counters we're talking
about increment once for each byte transmitted or received.  Looking at
it once doesn't help you much because you can't derive a rate from a
single sample.  If you have a lot of traffic perhaps one sample a minute
isn't good enough for you, especially if the traffic is bursty.  In a
situation like that you might want to sample every 5 or 10 seconds just
for fun to watch the ebb and flow of traffic on a link.


>>> "Luong, David" <[EMAIL PROTECTED]> 4/2/01 10:30:05 AM >>>
It makes more sense now. So it is like 2 polling cycle is MINIMUM in
order
to get a rate? I could use more than 2?

David.

-----Original Message-----
From: John Neiberger [mailto:[EMAIL PROTECTED]] 
Sent: Monday, April 02, 2001 8:25 AM
To: [EMAIL PROTECTED] 
Cc: [EMAIL PROTECTED] 
Subject: Re: utilization rate calculation


I'll try to restate this in a way that makes sense, but the text you
quoted says it pretty well.  The MIB data you are accessing is stored
as
a counter that increments for each byte transmitted and received. 
Let's
say you polled the router and got this information:

InOctets:  543980
OutOctets:  234095

Does that tell you anything?  Not really.  However if you wait a
minute
and poll it again you could see the amount of traffic in and out of
that
interface over a period of time, which gives you a rate.  A single
poll
will not give you any usefull information.  To get a rate, you need to
sample the data over time.  In this case the data is stored in bytes
so
you multiply times eight to get the rate in bits per second.

Does that help?  If not, I'll try again later after some more coffee. 
<g>

John

>>> "Luong, David" <[EMAIL PROTECTED]> 4/2/01 8:50:40 AM >>>
Hi Techies,

I have recenty been reading Cisco Press' new book called "Peformance
and
Fault Management" and they stated to measure utilization on a WAN
interface
(full-duplex); it is recommended to use the following formula:

max ( delta(ifInOctets), delta(ifOutOctets) x 8 x 100)
------------------------------------------------------
        (number of seconds in delta) x ifSpeed

They state because of "MIB II variables are stored as counters, you
must
take two poll cycles and figure the difference between the two" hence
the
delta number. I don't understand why two poll cycles are needed and
why
is
using "counters" attributed to this? 

Thanks,

David
____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

Reply via email to