[rrd-users] values being averaged.

[Simon Hobson]

<Richard.W.Brown at nokia.com> wrote:

>I had already read through the documentation, man pages and tutorials
>before posting. I had also spent some time with just trial and error
>where I wanted to clarify some of the examples as see what happened if.
>So your assumption was wrong :-)
>
>My biggest assumption was that the documentation was correct, this seems
>to be incorrect, as the tutorial rrd_beginners
>http://oss.oetiker.ch/rrdtool/tut/rrd-beginners.en.html states quiet
>clearly:
>"GAUGE does not save the rate of change. It saves the actual value
>itself. There are no divisions or calculations."

I would suggest that is incomplete rather incorrect. It will use the 
value supplied (ie not divide delta value by delta time to get a 
rate), but it will still normalise it (see the page on 
normalisation). rrdtool ALWAYS normalises data, but you can make the 
process a null operation by supplying data which exactly fits the 
normalisation process. Eg, with a five minute step, always supply the 
data EXACTLY on a multiple of 5 minutes, now "about 5 mins", not "5 
mins plus the time it took to run the command", but EXACTLY 5 minutes 
(and EVERY 5 minutes).

>And the man page rrdcreate
>http://oss.oetiker.ch/rrdtool/doc/rrdcreate.en.html states:
>"The data is also processed with the consolidation function (CF) of the
>archive. There are several consolidation functions that consolidate
>primary data points via an aggregate function: AVERAGE, MIN, MAX, LAST."
>
>And you say the above is not correct.
>
>It seems this tool will not do what I expected it to, and from your
>abrupt reply I do not expect to get a useful answer.  Also since you did
>not comment on the incorrect answer to he other post with a similar
>query, I will look elsewhere.

I would hang around a bit yet. If you saw the number of threads that 
start EXACTLY like yours did, ie appear to say "I did this, I got 
something else, therefore rrdtool is wrong" you would understand why 
you got the response you did. In almost all cases, the poster has not 
read the documentation, and expects rrdtool to work like a database 
(ie what you get out is exactly what you put in). The statement in 
the original post that "Well, since we all
know client connections can only be integer values this is obviously
wrong" does tend to make the query appear to fit into that large group.


The first thing you need to do is avoid consolidation during 
graphing. If the data points do not match the pixels, then the 
graphing stage will consolidate the data AS WELL AS any consolidation 
that was done while storing it. So you need to graph from 
'x-(pixels*step)' to 'x', where 'x' is an integer multiple of the 
step. So for example, with 5 minute sampling, you would want to graph 
from (say) 04:40 to 16:40, not from 04:42 to 16:42 if the graph width 
were 144 pixels wide. Thus take the current time, round it DOWN to 
the last whole multiple of step to get the end time, then subtract 
pixels*step to get the start time.

That will make a big difference to the graphs. Also note, that not 
having end time calculated like this can cause rrdtool to use a 
coarser consolidated dataset if that would fill the graph better. Eg, 
if you consolidated at 2mins and 5mins, then graphing to 16:05 might 
use the 5 min consolidation because it will have a value for the last 
minute of the graph, while the 2 minute consolidation would have a 1 
minute graph.