[mrtg] Re: MRTG and the "early data gathering" phenomenon (problem?) (fwd)

[Peter Stamfest]

On Thu, 28 Sep 2000, Alex van den Bogaerdt wrote:

> Date: Thu, 28 Sep 2000 00:55:07 +0200 (CEST)
> From: Alex van den Bogaerdt <alex at slot.hollandcasino.nl>
> To: Peter Stamfest <peter.stamfest at eunet.at>
> Cc: MRTG users <mrtg at list.ee.ethz.ch>
> Subject: Re: [mrtg] MRTG and the "early data gathering" phenomenon
>     (problem?) (fwd)
> 
> Peter Stamfest wrote:
> 
> > Now for the interesting part: When looking at the code of mrtg, I found
> > that there seem to be no provisions against "early data gathering". 
> 
> Look again then.  Also, check the docs; I'm pretty sure it is mentioned
> in more than one place:  MRTG doesn't care.

You are absolutely right.

I know that with the non RRD version, but with RRD I got (minor)
differences that I couldn't quite explain. Looking at it again, I see that
mrtg/RRD is doing some useful calculations with its data when it is
gathered even very unregularly.

Take the problem as solved, during the last couple of days my brain
seems to have been slighly out-of-order. I am ashamed.

peter

> 
> MRTG uses rates; bytes per second.  It will subtract the previous counter
> value (as available on line one of the log file) from the current one.
> It will also subtract the previous time stamp (again: 1st line) from the
> current one.  The rate is then calculated by doing deltaB/deltaT.
> 
> It doesn't matter if T is 300 seconds or 10 seconds, the resulting rate
> will be correct as it is per ONE second in both cases.
> 
> May I suggest an experiment:
> 
> Create a config file for one nearby interface.  Copy this config file
> to another name (say: mrtgtest1.cfg and mrtgtest2.cfg).
> Use separate directories for them or change the name of the targets.
> Use cron (or any other schedular) to start MRTG each interval (no daemon).
> For mrtgtest1.cfg the interval is 5 minutes (the normal time).
> For mrtgtest2.cfg the interval is 1 minute
> 
> The resulting graphs should be, approximately, the same.  If you also
> view the graphs with the "WithPeak" option, they will probably differ
> on the maxima as you're monitoring with a higher sample rate.
> 
> > before? Or an I totally wrong?
> 
> Not totally: see below.
> 
> > 3. A third possibility would be to put some restart logic into mrtg, that
> > restarts mrtg when the configuration file changes (just doing a "exec
> > mrtg ... " should suffice I guess, but I didn't think about it too much
> > yet).
> 
> You present this as a solution for a problem that isn't there.  However,
> I do think this will be a valuable addition to MRTG in daemon mode.
> The config file will change from time to time and in stead of stopping
> and starting the MRTG process by hand, it may be nice to have MRTG read
> the new config file.
> 
> Not everybody will like this behaviour.  If you do work on this extension,
> perhaps it would be better to make it optional.
> 
> regards,
> 



--
Unsubscribe mailto:mrtg-request at list.ee.ethz.ch?subject=unsubscribe
Archive     http://www.ee.ethz.ch/~slist/mrtg
FAQ         http://faq.mrtg.org    Homepage     http://www.mrtg.org
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi