You probably already saw Jennifer's post on the separation of rxload and
txload and adjusting the load interval.
After I saw her post, I looked up 'load-interval' and saw something
relatively surprising: The example of the using load fraction was to
provide a mechanism for enabling dial backup, and not for monitoring load on
the inteface (which is how most of us use it). Interesting how we took that
value and used it (probably not for the intent that it was provided).
There are routing protocols that also use it, though, which makes it very
important to set the bandwidth parameter properly on interfaces.
from the 'what difference does it make' perspective, it could make a
difference in the case of having multiple metrically identical paths to the
same destination - for example, EIGRP has as part of its metric calculation
the 'bandwidth/(256 - load)' factor, but by default it is disabled. If it
were enabled, the routing metric would change, and the preferred EIGRP route
would become the less-loaded interface. (Did someone say 'load balancing?
;-)
from the perspective of monitoring a link, it makes a difference knowing
that you are saturated from a Tx perspective so you can do some kind of
bandwidth grooming/limiting or to determine (as you have before) if you need
to consider a circuit upgrade. If you sustain that Tx load at 80% and
higher over all business hours in a day, for example, that's a good
candidate for fixing something. If there are occassional 5 minute average
bursts of 100%, but sustained bandwidth at 30-50%, that's a different
situation, and you can do some investigation around those bursts.
Traffic engineering is an entire science of itself, one that has alternately
fascinated and frustrated me over the years. My boss used to ask, "When
should we upgrade that frame relay circuit?", or "When should we convert
from 10BaseT to FastEthernet?". My answer (before I understood as much as I
do now) was, "When the users start to complain about performance or when
their department can absorb the cost of the upgrade." I don't use the same
metrics for service upgrades anymore. ;-)
-e-
----- Original Message -----
From: "David Chandler"
To:
Sent: Thursday, April 26, 2001 2:58 PM
Subject: Re: Utilization/load Calculations [7:2167]
> What bothers me is that using a comprehensive calculation (input and
> output combined) on ANY full-duplex connection seams meaningless. What
> difference does it make if there is still bandwidth to spare on the Rx
> side when the Tx is maxed out?
>
> Your thoughts??
>
> DaveC
>
> Yes: when I say 5 minute movin average, I mean the exponential average.
> I have the formula around here some where.
>
> EA Louie wrote:
> >
> > the definition of load from Cisco:
> > Load on the interface as a fraction of 255 (255/255 is completely
> > saturated), calculated as an exponential average over five minutes.
> >
> > I don't personally have access to the formula, nor could I find it on
> > Cisco's website.
> >
> > If this were a multiple choice problem on the certification exams, I'd
rule
> > out answer 2, because neither input or output is comprehensive in and of
> > itself
> >
> > If 'moving average' means exponential average, then I'd choose answer 1
in
> > conjunction with answer 3.
> >
> > The utilization (based on the sh int load value) doesn't make any sense
> > *unless* the bandwidth parameter on the interface is set to reflect the
> > actual bandwidth of the circuit.
> >
> > We had a tool once that extracted both the input/output bps averages and
> the
> > drops, and calculated *them* across a few seconds against the circuit
> > bandwidth - it gave us a little better granularity and accuracy,
especially
> > if the drops corresponded with higher 'load'.
> >
> > Also, my experience has been that as the sustained (not burst) pps/bps
> > interface utilization approaches the CIR bandwidth of a frame relay
> circuit,
> > the performance of the PVC starts to degrade. Lots of buffered packets
> will
> > tend to do the same, so bursts on a point-to-point serial link cause the
> > same problem.
> >
> > ----- Original Message -----
> > From: "David Chandler"
> > To:
> > Sent: Thursday, April 26, 2001 1:05 PM
> > Subject: Utilization/load Calculations [7:2167]
> >
> > > Hi all:
> > >
> > > How is the "Load" calculated on a serial interface, or any interface
for
> > > that matter?
> > >
> > > Does it:
> > > 1. Use some weird formula like the 5 minute moving average? >
dreamed
> that thing up?
> > > 2. Use the greater of the input or output bps?
> > > 3. Add the current (input + output) bps together and ratio it against
> > > the max possible (input + output) bps?
> > > 4. none of the above. >
> > > We often use ciscoview to monitor circuits for error, dropped packets,
> > > input/output bps etc. (It is a lot better than having to keep
refreshing
> > > your telnet sh int..sh int...sh int..) The utilization which comes
from
> > > the load never really seems to make any sense. For example: if the Tx
is
> > > maxed out the utilization does not indicate it... I gave up looking
at
> > > load/utilization a long time ago. Unfortunately my coworkers seem to
> > > think that unless the utilization (via Ciscoview) is high that the
slow
> > > response issues have to be caused by something else. Needless to say;
> > > when the circuit is upgraded and the slow response issues clear, there
> > > is a lot of political knife sharpening...
> > >
> > > TIA
> > >
> > > DaveC
> > >
> > > PS: I did check archives. After 100+ messages not telling me what I
> > > wanted to know; decided this was a group Question.
> > > FAQ, list archives, and subscription info:
> > http://www.groupstudy.com/list/cisco.html
> > > Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
> FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
> Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=2298&t=2167
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
