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

[Alex van den Bogaerdt]

From: "Wesley PA4WDH" <pa4wdh at yahoo.com>
To: <rrd-users at lists.oetiker.ch>; "Alex van den Bogaerdt" 
<alex at vandenbogaerdt.nl>
Sent: Sunday, February 17, 2013 1:53 PM
Subject: Re: [rrd-users] Strange behavior when using CDEF to divide two 
values


> Hi Alex,
>
> At least i thought i did understand :-)
> I also see that the values stored in the RRD databases are not the exact 
> values i store in it, as far as i know a result of normalisation.

Probably.

> The part i do not understand is that it may occour during graphing. The 
> two datasources are stored in the same database and normalized so i 
> wouldn't expect any normalization during graphing.

Correct. Normalizing occurs before the rates are stored in an RRA.

> I don't think consolidation will have any role in this situation since i'm 
> only using one RRA to store a day of 5-minute samples, not the data is not 
> consolidated any further.

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.

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.

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.

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.

HTH
Alex