[rrd-users] Re: Manipulating and Graphing Data

Simon Hobson linux at thehobsons.co.uk
Tue Oct 31 07:49:50 MET 2006

Tony Varriale wrote:

>Hi...thanks for the info.  I did try DERIVE but I get very inaccurate results.
>For example:
>I had about 400 drops in the queue that were generated.  The graphs 
>and data were showing anywhere from 8-16 drops.  I again verified 
>the actual data with a manual snmpwalk.
>When I have DS type set to GAUGE, the data is very accurate 
>(probably <5% off) but I am unable to get the difference between the 
>current value and the previous.  The graph, obviously, keeps 
>expanding on the y-axis.
>So, with DERIVE, I am assuming rrdtool takes the value (400) and 
>divides it by the update rate specified when creating the rrd (300 

Closer, but it uses the values supplied AND THE TIME INTERVALS to 
work out the rate over each interval defined in your rrd. If your 
updates EXACTLY match the time intervals then the rate stored will 
match the value you put in, otherwise it will be adjusted.

>Any ideas on how to solve this?

There is nothing to solve, other than putting the right stuff in.

>Also, maybe I misunderstood the documentation but this is what I 
>have previously read: "The original value you have supplied is 
>stored as well and is also taken into account when interpolating the 
>next log entry."  Is this not true?

Yes it is true, but does not mean what you think. It states that the 
value you put in is kept so that when the next update comes along 
rrdtool can correctly work out the change. Only one value is kept, 
the data you can read from the rrd for graphing is all the result of 
processing your updates.

Taking the figures above, if you do an update with value 0 at time 0, 
then an update with value 400 at time 400, then the stored value will 
be 400/300 or 1.3333. If you next update was at time 600 with value 
800, then again the rate would be (800-400)/300 = 1.3333.

However, if you updated with the same values but at different times, 
say 0 at 150, 400 at 450, and 800 at 750  ...
The interval 0-300 seconds would get 0 from 0 to 150, plus 
400*(150/300) - ie the second sample would be split between the first 
and second intervals. The total would therefore be 200 over the 
interval and the rate stored would be 200/300 or 0.66666.
In the next interval, you get the remainder of the input plus a 
proportion of the next which as we are dealing with a simplistic 
steady rate will give you the value you might have been expecting.

Time intervals all start with 0 at the unix beginning of time back in 
1970, so if you take t as the current time in seconds, and i as the 
rrd interval, then the current period starts at t - (t % i), and the 
next starts at t-(t%i)+i and so on.

Unsubscribe mailto:rrd-users-request at list.ee.ethz.ch?subject=unsubscribe
Help        mailto:rrd-users-request at list.ee.ethz.ch?subject=help
Archive     http://lists.ee.ethz.ch/rrd-users
WebAdmin    http://lists.ee.ethz.ch/lsg2.cgi

More information about the rrd-users mailing list