Unless you really want 5-minute decaying averages, you may want to
use the "load-interval" set to 1 minute or 30 seconds. This cause
more frequent updates to the "show interface" counters and gives you
a more immediate "current rate".
Whether it'll move toward convergence of rate vs. count is another
question.
Two other common MRTG problems are missing sample leading to premature
32-bit counter wrap, and pulling or seeing a "bandwidth" setting when
making the config that's saves as "absmax" in the config which MRTG
uses to throw away "excessive samples".
64-bit counters appears to work fairly well, where available, exactly
which interfaces include 64-bit support is verssion dependent, often
you'll have half the interfaces in a router with 64-bit counters and
half with 32-bit...
George
> From cisco-nsp-request@puck.nether.net Tue Nov 13 14:43:21 2001
> Resent-Date: Tue, 13 Nov 2001 14:43:12 -0500
> Received-Date: Tue, 13 Nov 2001 14:40:18 -0500
> Date: Tue, 13 Nov 2001 20:40:48 +0100
> From: Gert Doering <gert@greenie.muc.de>
> To: deepak@ai.net, "Cisco-Nsp@Puck. Nether. Net" <cisco-nsp@puck.nether.net>
> Subject: Re: [nsp] bit rate accuracy?
> In-Reply-To: <GPEOJKGHAMKFIOMAGMDIGENCGMAA.deepak@ai.net>; from Deepak Jain on Tue, Nov 13, 2001 at 12:30:51PM -0500
> X-mgetty-docs: http://alpha.greenie.net/mgetty/
> Resent-From: cisco-nsp@puck.nether.net
> X-Mailing-List: <cisco-nsp@puck.nether.net> archive/latest/8207
> X-Loop: cisco-nsp@puck.nether.net
> List-Post: <mailto:cisco-nsp@puck.nether.net>
> List-Help: <mailto:cisco-nsp-request@puck.nether.net?subject=help>
> List-Subscribe: <mailto:cisco-nsp-request@puck.nether.net?subject=subscribe>
> Precedence: list
> Resent-Sender: cisco-nsp-request@puck.nether.net
>
> Hi,
>
> On Tue, Nov 13, 2001 at 12:30:51PM -0500, Deepak Jain wrote:
> > If I remember correctly, Cisco uses some kind of decaying average algorithm
> > to report bit rate/second on interfaces.
>
> Yep.
>
> > MRTG and programs like it use regular polling of byte counters. If the
> > latency of the network is constant and both the statistics machine and the
> > network device have sufficient available CPU, it seems to me that MRTG
> > statistics will be more accurate over a 5 minute window.
> >
> > The reason I am asking is because I have a full duplex FE interface that is
> > reporting 94mb/s inbound on a 5 minute average, and yet the MRTG is never
> > exceeding 84.2mb/s on the same interface.
>
> It always depends which bugs you're hitting and over which time you're
> averaging...
>
> We're reading the SNMP octet counters, the "show int" octet counters, and
> both SNMP and "show int" 5 minute average values. All of those values
> are read every 5 minutes, averaged over the day, and then compared, and
> the results differ wildly (interesting enough, SNMP and "show int" values
> differ by up to 20% for the 5 minute average counters - interesting,
> isn't it?).
>
> The most exact seems to be the SNMP octet counters so far, especially on
> high speed interfaces when you have counter64 available (and if they
> happen to work).
>
> The problem with the octet counters is that they are not "so nice to look
> at" - with the 5 minute averages, you can just look at an interface and
> see what's going on. With octet counters, you always have to calculate
> the deltas - easy for a machine, cumbersome by hand.
>
> So both types of counters have their merits.
>
> > [MRTG is configured as a daemon so cron-timing shouldn't be an issue]
>
> Actually if you sample every 5 minutes, and note down the exact time when
> the sample was read, it doesn't really matter whether one sample is
> delayed by a few seconds (or even minutes) - you have to know the time
> difference between the two samples anyway to calculate the average, and
> if you query the router later, the counter will be accordingly larger...
>
> gert
>
> --
> USENET is *not* the non-clickable part of WWW!
> //www.muc.de/~gert/
> Gert Doering - Munich, Germany gert@greenie.muc.de
> fax: +49-89-35655025 gert.doering@physik.tu-muenchen.de
>
>
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:12:54 EDT