[mrtg] Re: Problem with the way MRTG takes samples.

Alex van den Bogaerdt alex at slot.hollandcasino.nl
Sat Sep 4 02:15:28 MEST 1999


> 
> MRTG seems to me assuming or "faking" these EPOC#s so that the difference
> between 2 will always be 300 seconds!?
> 
It is not assuming it, and I wouldn't call it faking.
MRTG is not logging exact counter values, it is logging rates. When
you monitor some value over some time, you can divide this by
some time and end up with some other value per second.

> Problems:
> 
> -The way you calculate bps from SNMP octets is:
>    ((CurrentOctet - LastOctet) / Seconds) * 8

Correct, however mrtg is not logging bits, it is logging octets.
(  (octetNow - octetLast) / (timeNow - timeLast) )

>  where:
>    CurrentOctet = the current interface in or out octets read via SNMP
>    LastOctet = the last in or out octets that were read via SNMP
>    Seconds = the number of seconds that have elapsed between the pulling
>              of the LastOctet and the CurrentOctet
>  You would calculate Seconds by getting the difference between the last
>  EPOC# and the current EPOC#.  If Seconds isn't correct/real, the bps will
>  be wrong.

But it isn't. Notice that the first few lines in the log are **not** on
exact 5-minute boundaries.

> -Also because MRTG is "faking" the EPOC#s, the time that the in and out
>  octets were pulled is wrong, causing the timeline of the data to be up to
>  5min off.
> 
Yes and no. This would be correct if your computer would be able to display
fragments of a pixel. (contradiction in terms ?) It is most likely not, so
the problem does not exist.

If your samples are 310 seconds apart, the delta will be higher than when
it would be 300 seconds apart. In both cases, you will end up with approx.
the same amount of octets per second. Any error will be corrected in the
next sample. Now for the shift, a rate taken between 12:32 to 12:37 will
most likely be very close to the rate between 12:30 and 12:35.

Larger errors are:
- rounding down to integers (12.5 octets/sec --> 12 octets/sec)
- smoothing the peaks (1 min. @ a rate of 120, 4 mins @ 0 --> 5 mins at 20)

HTH,
Alex

--
* To unsubscribe from the mrtg mailing list, send a message with the
  subject: unsubscribe to mrtg-request at list.ee.ethz.ch
* The mailing list archive is at http://www.ee.ethz.ch/~slist/mrtg


More information about the mrtg mailing list