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:[EMAIL PROTECTED] Sent: Friday, February 01, 2002 4:44 PM To: Mike McHenry Cc: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] > 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:[EMAIL PROTECTED] > Help mailto:[EMAIL PROTECTED] > Archive http://www.ee.ethz.ch/~slist/rrd-developers > WebAdmin http://www.ee.ethz.ch/~slist/lsg2.cgi > > > -- > Unsubscribe mailto:[EMAIL PROTECTED] > Help mailto:[EMAIL PROTECTED] > 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 /_/ \.__/_.__/_/ [EMAIL PROTECTED] http://google.com/search?q=tobi -- Unsubscribe mailto:[EMAIL PROTECTED] Help mailto:[EMAIL PROTECTED] Archive http://www.ee.ethz.ch/~slist/rrd-developers WebAdmin http://www.ee.ethz.ch/~slist/lsg2.cgi
