[rrd-developers] Re: Bug with CDEF processing
Mike McHenry
mmchenry at origix.net
Sat Feb 2 00:15:23 MET 2002
That makes sense, the error that I was seeing basically caused multiple
datasources to come out with the same data in CDEF statements. I am not
familiar enough with the code to know for sure but I believe this can be
reverted back to the old code with no ill effects elsewhere.
On another note, with this work I have actually put together an RPM
package of the development code branch (specifically the pre-aa freeze)
that seems to be completely functional and stable. I can now do total
bandwidth / 95th percentile graphing / using rrdtool. All of the VDEF
code seems to work for me QUITE well including the TOTAL and PERCENT
features. I know there are a LOT of people out there who could use this
so if there is any interest I would be happy to make this "source
freeze" available for others to use. Feel free to download source and
binary RPMs at ftp://development.origix.net/pub/
Thanks Tobias for your help and especially this program, time to order a
CD me thinks. :)
Mike McHenry
Senior Network Engineer
Origix Corp.
-----Original Message-----
From: Tobias Oetiker [mailto:oetiker at ee.ethz.ch]
Sent: Friday, February 01, 2002 4:44 PM
To: Mike McHenry
Cc: rrd-developers at list.ee.ethz.ch
Subject: Re: [rrd-developers] Re: Bug with CDEF processing
Today Mike McHenry wrote:
>
>
> Ok, I think I have somewhat answered my own question. The bug appears
to
> be located in this diff of code between CVS-2001-10-24 and
> CVS-2001-10-25, line 777 of the rrd_graph.c code.
>
> diff -uNr rrdtool.good/src/rrd_graph.c rrdtool.bad/src/rrd_graph.c
> --- rrdtool.good/src/rrd_graph.c Fri Dec 21 20:49:23 2001
> +++ rrdtool.bad/src/rrd_graph.c Mon Dec 24 00:51:49 2001
> @@ -777,8 +791,7 @@
> * further save step size and data source
> * count of this rra
> */
> - im->gdes[gdi].rpnp[rpi].data =
> - im->gdes[ptr].data +
im->gdes[ptr].ds;
> + im->gdes[gdi].rpnp[rpi].data =
im->gdes[ptr].data;
> im->gdes[gdi].rpnp[rpi].step =
im->gdes[ptr].step;
> im->gdes[gdi].rpnp[rpi].ds_cnt =
im->gdes[ptr].ds_cnt;
>
> Anyone comments? Without this patch the CDEF problems that I commented
> on below go away...
Hi Mike,
The Patch was done by alex, so maybe he can comment. The original
code (mine) had the intention of storing a pointer to the start of
the data of each datasource within an RRA. (rrd_fetch allways
fetches the whole RRA from the RRD. If the RRA contains several
Datasources, it is arranged in several columns like this:
abcd
abcd
abcd
abcd
the code above was saving a pointer to the start of each column
(hence the +...ds) ...
cheers
tobi
>
> Mike McHenry
> Senior Network Engineer
> Origix Corp.
>
>
> -----Original Message-----
> From: Mike McHenry
> Sent: Friday, February 01, 2002 1:32 PM
> To: rrd-developers at list.ee.ethz.ch
> Subject: [rrd-developers] Bug with CDEF processing
>
>
> I have been beating my head over this one but there appears to be a
bug
> in the way CDEF statements are processed in the current code base. I
> have looked back and this bug seems to have been introduced on
> 12/25/2001.
>
> Basically appears to happen is that multiple CDEF definitions seem to
be
> blending the variables together. For example, take a simple database
> with two sets of variables in it and run the following command....
>
> rrdtool graph /tmp/test.gif -s 1012261801 -e 1012278000 \
> DEF:input=database.rrd:input:AVERAGE \
> DEF:output=database.rrd:output:AVERAGE \
> CDEF:inputBits=input \
> CDEF:outputBits=output \
> GPRINT:input:AVERAGE:"Input average %1.2lf" \
> GPRINT:output:AVERAGE:"Output average %1.2lf"
>
> What seems to happen is that the two CDEF statements somehow seem to
> become intertwined and end up being printed as the same value in the
> final GPRINT statements (even though the datasets are definitely not
the
> same values). This appears to be a bug in the CDEF code and I am
> wondering if anyone has any input or can point me in the right
> direction.
>
> I have narrowed down the bug to something that was introduced on
> 12/25/2001. The 12/24/2001 CVS code does not exhibit this problem. It
> looks like the patch between the two versions was pretty significant
so
> I am at a little bit of a loss as to where to start looking for the
> problems. Any suggestions would be appreciated, thanks!
>
> Mike McHenry
> Senior Network Engineer
> Origix Corp.
>
>
>
> --
> Unsubscribe
> mailto:rrd-developers-request at list.ee.ethz.ch?subject=unsubscribe
> Help mailto:rrd-developers-request at list.ee.ethz.ch?subject=help
> Archive http://www.ee.ethz.ch/~slist/rrd-developers
> WebAdmin http://www.ee.ethz.ch/~slist/lsg2.cgi
>
>
> --
> Unsubscribe
mailto:rrd-developers-request at list.ee.ethz.ch?subject=unsubscribe
> Help mailto:rrd-developers-request at list.ee.ethz.ch?subject=help
> Archive http://www.ee.ethz.ch/~slist/rrd-developers
> WebAdmin http://www.ee.ethz.ch/~slist/lsg2.cgi
>
>
--
______ __ _
/_ __/_ / / (_) Oetiker, ETZ J97, ETH, 8092 Zurich, Switzerland
/ // _ \/ _ \/ / phoneto:+41(0)1-632-5286 faxto:+41(0)1-632-1517
/_/ \.__/_.__/_/ oetiker at ee.ethz.ch http://google.com/search?q=tobi
--
Unsubscribe mailto:rrd-developers-request at list.ee.ethz.ch?subject=unsubscribe
Help mailto:rrd-developers-request at list.ee.ethz.ch?subject=help
Archive http://www.ee.ethz.ch/~slist/rrd-developers
WebAdmin http://www.ee.ethz.ch/~slist/lsg2.cgi
More information about the rrd-developers
mailing list