[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
>seconds).
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