[rrd-users] Re: Graphs wrong after reboot - samples included

[George Dau]

No, setting maximum values for the counters is not a complete solution. If
the counters get reset when the value of the counter is high, you will get a
wrap that produces a wrong result that is also less than the maximum you set
and thus will be recorded as a value. You still get wrong data in your
database.

I went with the DERIVE data type. You miss one entry when there is a counter
wrap, which for me is better than having a wrong entry. I put quite a bit of
testing and thought in to this, and DERIVE is definitly the best for my
data.

-----Original Message-----
From: Michael Wells [mailto:michael at wells.org.uk]
Sent: Saturday, 18 August 2001 7:03 AM
To: RRD users
Subject: [rrd-users] Re: Graphs wrong after reboot - samples included



Hi,

Your description highlighted the problem with my graphs. The affected RRDs
with counters in them have been adjusted to have proper limits (solution
number 2), and the problem has now vanished. I've also made my .png images
into, erm, PNGs. ;-)

Here is my updated RRD definition. This is a 100Mb/s NIC.

#/bin/sh

   rrdtool create rl0.rrd         \
            DS:input:COUNTER:3600:0:12500000  \
            DS:output:COUNTER:3600:0:12500000 \
            RRA:AVERAGE:0.5:1:600      \
            RRA:AVERAGE:0.5:6:700      \
            RRA:AVERAGE:0.5:24:775     \
            RRA:AVERAGE:0.5:288:797    \
            RRA:MAX:0.5:1:600          \
            RRA:MAX:0.5:6:700          \
            RRA:MAX:0.5:24:775         \
            RRA:MAX:0.5:288:797

Thanks very much for the detailed explanation, Alex!

Best wishes
Michael

-----Original Message-----
From: rrd-users-bounce at list.ee.ethz.ch
[mailto:rrd-users-bounce at list.ee.ethz.ch]On Behalf Of Alex van den
Bogaerdt
Sent: 17 August 2001 19:36
To: Michael Wells
Cc: RRD users
Subject: [rrd-users] Re: Graphs wrong after reboot - samples included



Michael Wells wrote:
>
> I'm finding that when I reboot, the graphs I get are fouled up. An
> example of what the graph looks like before and after reboot is here:
>
> http://www.wells.org.uk/rrdtools/before.png
> http://www.wells.org.uk/rrdtools/after.png

I need to download these files and rename them to *.gif before I'm
able to view them.  Did you forget to use '--img-format PNG' ?

>    rrdtool create rl0.rrd         \
>             DS:input:COUNTER:3600:U:U  \
>             DS:output:COUNTER:3600:U:U \

Unlimited counters...  so indeed, a reboot results in the counter
being reset to zero.  If the front end doesn't check the uptime of
the counter, it will be processed as a wrap.

If the current counter value is below the last-seen counter value
then the difference (which is negative) should be incremented with
2**32.  If it is below zero thereafter, increment with (2^64 - 2^32)

In most cases, 2^32 will have been added.  This is 4294967296 bytes
which are assumed to have passed the interface somewhere between the
previous update and the current one. You write you update every
few minutes.  However, your RRD is using 300 second intervals.  To
get the resulting numbers (about 12MBps and about 26MBps) you have
to have been updating every three minutes if I'm not mistaking. I
also suspect you booted (at least) twice around 18:00

How to solve the problem and the resulting problem:

1) Your front end should check wraps.  If it is not a real wrap or
   if it is not sure to be a wrap, update with "U" instead.
2) If (1) is not possible or not feaseble, set proper limits on the
   DS.  For 10Mbps ethernet this should read "...3600:0:1250000"
3) dump, edit and restore the RRD to get rid of the spike.  Search
   for "2\.6.........e+06" (where \. means a decimal point and . means
   a character wildcard) in the .xml file.

I think there is a script to do (3) but you really want to have a look
in such an xml file at least once before automating it.

cheers,
--
   __________________________________________________________________
 / alex at slot.hollandcasino.nl                  alex at ergens.op.het.net \
| work                                                         private |
| My employer is capable of speaking therefore I speak only for myself |
+----------------------------------------------------------------------+
| Technical questions sent directly to me will be nuked. Use the list. |
+----------------------------------------------------------------------+
| http://faq.mrtg.org/                                                 |
| http://rrdtool.eu.org  --> tutorial                                  |
+----------------------------------------------------------------------+

--
Unsubscribe mailto:rrd-users-request at list.ee.ethz.ch?subject=unsubscribe
Help        mailto:rrd-users-request at list.ee.ethz.ch?subject=help
Archive     http://www.ee.ethz.ch/~slist/rrd-users
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi



--
Unsubscribe mailto:rrd-users-request at list.ee.ethz.ch?subject=unsubscribe
Help        mailto:rrd-users-request at list.ee.ethz.ch?subject=help
Archive     http://www.ee.ethz.ch/~slist/rrd-users
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi


**********************************************************************
The information contained in this e-mail is confidential and is
intended only for the use of the addressee(s).
If you receive this e-mail in error, any use, distribution or 
copying of this e-mail is not permitted. You are requested to
forward unwanted e-mail and address any problems to the 
MIM Holdings Limited Support Centre.

e-mail: supportcentre at mim.com.au
phone: Australia 1800500646
            International ++61 7 38338042
**********************************************************************

--
Unsubscribe mailto:rrd-users-request at list.ee.ethz.ch?subject=unsubscribe
Help        mailto:rrd-users-request at list.ee.ethz.ch?subject=help
Archive     http://www.ee.ethz.ch/~slist/rrd-users
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi