[rrd-users] Strange behavior when using CDEF to divide two values

[Wesley PA4WDH]

Hi Alex,

Thanks for your answer.

--- On Mon, 2/18/13, Alex van den Bogaerdt <alex at vandenbogaerdt.nl> wrote:
> For example: if you are using 1200 of those 5-minute
> samples, and are 
> graphing 600 pixels wide, RRDtool has no choice but to
> consolidate 2 samples 
> into 1, 600 times. Things become more complicated if you
> have start and end 
> times not on a logical boundary, or if (end-start)/300 is
> not a whole 
> multiple of horiz_pixels, and so on.

Ah, i see, i did not think about that but it sounds logical. So i guess my first take at troubleshooting should be to make the width of the graph >= the number of samples to rule out the effect of consolidation.
Which consolidation fuction is used for this operation ? If it the one i defined at the RRA ?
 
> Dividing by _almost_zero_ does not produce NaN, it produces
> a very high 
> number. That is what you encountered. So this supports my
> hunch; you are not 
> looking at zero, you are looking at 1e-10, or you are
> looking at 
> {zero+something}/2. Or maybe {zero*3+something}/4, and so
> on.

This is indeed something i was looking at, but i couldn't find such numbers in the RRA, but your theory sounds in line with the result. Thanks.
 
> Don't get me wrong, there is always the possibility of a
> bug, but that would 
> not be my first thing to investigate if I would tackle this
> problem.

I'm not saying this is a bug, i'm using the same setup to calculate an average packet size on network interfaces and there it works as expected. So a but would not be likely.
 
> For some it's a nice excercise to dive into this and analyse
> the situation. 
> For others it's a wast of time, and they should hire someone
> to do the job. 
> You know best in which category you fit best.

In my case it's just a personal experiment so i'm happy wasting a lot of time on it and learning something along the way :-)

Best regards,
Wesley