[mrtg] Re: Logfile Question

[Alex van den Bogaerdt]

On Thu, Nov 28, 2002 at 05:53:04PM +0000, Barry_Young at interliant.com wrote:

> So if we are polling every 5 minutes (as shown by the increasing time value
> in the log file. eg. 300 second increments) and these are recently "daily"
> polled details therefore still being averaged over 5 minutes, how can there
> be so much variance between columns 2&4 and 3&5.  In some instances over
> twice as much traffic is detected.
> 
> 1038500700 231 1020 298 1080
> 1038500400 139 450 205 1080

Maximum:  MRTG "knows" it got a rate of 1080 (current counter minus
last counter, divide by time lapsed).

The interval 1038500400-300 to 1038500400 and the interval
1038500700-300 to 1038500700 have a *normalized* rate (look this up
on faq.mrtg.org).

The measured rate of 1080 was from, for example, 1038500363
to 1038500631.  This is not a 300-second interval and also is not
on "nice" boundaries in time.  For efficiency, MRTG will normalize
the rate.

The rate of 1080 was valid from 1038500363 to 1038500631.  This means
that in the normalized interval of 1038500100 to 1038500400 the rate
seen was 1080 (and in your case it was the highest rate seen). The
next normalized interval from 1038500400 to 1038500700 also has a
maximum seen rate of 1080.

1020 octets per second is the rate for the normalized interval from
1038500400 to 1038500700.  This means that in this normalized interval
300 times 1020 octets have been output.  The measured average rate
was 1080 however this didn't last throughout the entire time period.

For instance (and I'm sure the numbers won't match exactly as I just
take an educated guess here) you're monitoring the device at multiples
of 5 + 4 (hh:04, hh:09, hh:14, hh:19 and so on).  During 4/5 of a
normalized interval the rate was 1080.  The other 1/5 of the interval
will account for the remainder of the normalized rate:

1020 = 4/5*1080 + 1/5*n -->  n=780


The rate 1080 is measured from 1038500700-300 to 1038500700 + 4*300.
The rate is then normalized; the 1038500700-300 to 1038500700 goes
to the previous interval, 1038500700 to 1038500700+4*300 goes to this
interval, the remainder (at rate 780) comes from the next measurement.


The nett result, apart from rounding errors, is that the average rate
of any time span times this time span equals the amount of bytes sent
throughout this time span.


Compare with the next example:

Time 00:00 your counter value is 0.
Time 00:05 your counter value is 600.

vs.

Time 00:00 your counter value is 0.
Time 00:01 your counter value is 0.
Time 00:02 your counter value is 0.
Time 00:03 your counter value is 360.
Time 00:04 your counter value is 600.
Time 00:05 your counter value is 600.


In the first case MRTG would compute an average rate of 2 (per second)
which would also be the highest rate seen.  In the other case, MRTG
would see an increase of 360 octets in 60 seconds (00:02 to 00:03) as
the highest rate (6 per second) and an average of 2 again.


In both cases the log file would store an average of 2 and you can
multiply this average by 300 to get the total amount of octets.

For a more elaborate example of how normalizing works, see the faq.


HTH
Alex

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