[rrd-users] Dynamic Steps
Alex van den Bogaerdt
alex at vandenbogaerdt.nl
Sat Apr 20 11:17:19 CEST 2013
Please just do some experiments with fake data.
Create two databases with the same property, ABSOLUTE counter type. Update
them using the same timestamps (do not use "N"), four times a second, and
make sure there is enough data to fill a couple of timeslots in your RRA.
Feed 3600 into one RRD every time, feed 1 into the other RRD every time.
You should see a rate of 14400 in the first, and 4 in the other.
Now use a CDEF to multiply 4 by 3600, and you get 14400 again. Same
resulting rate, other way to achieve it. The resulting databases have
Joules/second in the first, and Wh per second in the other. That CDEF
transforms Wh into J, because 1 Wh is just 3600 J.
Do not confuse this with another reason to multiply by 3600. You have been
asking about 'per hour' rates. If you have 1 Wh per second, constantly, then
after an hour you will have used 3600 Wh. So if you multiply a rate by 3600,
you get 'rate per hour' instead of 'rate per second'.
If your database contains Wh, and you want to know Joules/hour, then you
need to multiply by 3600 twice (or one time by 12960000, for performance
And to answer your question about where RRAs get their data: it is already
described. PDPs are used to build CDPs. See the three phase description
again. If RRAs get their data from other RRAs, it would have been described
Really, you are thinking and assuming a lot, but you do not verify this by
Start simple. Step==60 (meaning: every step is 60 seconds). Update with
timestamps that are a whole multiple of 60 (n*60). Start simple with three
RRAs, one using 1 PDP per CDP, one using 2 PDP per CDP and one using 3 PDP
per CDP. See what happens, and when it happens, by examining the resulting
RRD every time between updates.
Later you start updating with timestamps that are not a whole multiple of 60
seconds, e.g. at n*60+10, and you learn about normalization.
Try updating a couple of times per step (e.g. every 15 second, n*15), try
updating less than one time per step (e.g. every 5 minutes, n*300). Play
with the heartbeat setting when you do this. Set it to 600 in one of your
experiments, and set it to 60 in another (with all other parameters and
updates being equal). Why does your data become unknown? You do not need to
ask, because you will know.
There are many other experiments to think of. Whenever the result are not
corresponding with what you believe to be true, chances are your beliefs are
incorrect and you should experiment further and read more manual pages. I'm
not saying there are no bugs in RRDtool, but the topics we covered are used
by so many people that I think bugs if any have been found and solved
already, a decade ago.
----- Original Message -----
From: "Oliver Loch" <grimeton at gmx.net>
To: "Alex van den Bogaerdt" <alex at vandenbogaerdt.nl>
Cc: "Alan Finlay" <alan.websites2 at chankly.com>; <rrd-users at lists.oetiker.ch>
Sent: Friday, April 19, 2013 6:43 PM
Subject: Re: [rrd-users] Dynamic Steps
> But in the case of Wh, I recommend to multiply 'ticks' by 3600 at input
> time, because each tick is worth 3600 Joules, and this results in a clean
> database storing Joules per second aka Watt. Although this could also have
> been done in a CDEF, it just does not "feel right".
How could that be done with an CDEF? Let's assume the W/h example. As far as
I understand it and based on the information in your e-mail, the CDEF
language only works with CDPs. So if there is a CDP every second, and the
CDP - steps can't be below one second, multiple ticks per second would be
used to calculate the average of the CDP-step and stored in that particular
So imho trying to solve this via CDEF wouldn't work as we already lost the
exact data that we'd need to calculate it. Only thing I could think of would
be to add more steps per second (which isn't possible) or trying to use more
CDP per hour. Like 7200 which would give me "CDP Steps" at the range of
0.5s. But as this isn't possible one idea could be to just "jump" multiple
steps per second and use that information later when creating the graph.
E.g.: Four "steps" per second would give me 14400 steps per hour. So every
second stuff is written to a CDP it just forwards four steps instead of one.
and only fills as much steps as there were ticks. So four CDPs per second,
three ticks that second, it moves forward 4 CDPs and then fills the last
But I also have another question that isn't really clear to me:
Let's assume again that I'm monitoring the power meter.
The database has one source, which is the "tick"-counter that has 3600 steps
and uses the ABSOLUTE counter. Now I add multiple RRAs. First one is for an
whole hour with an per minute average. So I store 60 CDPs that are created
with 60 CDPs from the datasource. Now I'm also creating an RRA that holds
the average per hour and requires ??? CDPs to populate one CDP. The question
is - if defining multiple RRAs, are they all referencing the main data
source or are RRAs that store data over a long time, less exact, referencing
to the "smaller" RRA?
So. what happens if I have 3600 steps per hour and the only RRA does the
average of two hours? Is rrdtool smart enough to handle that?
More information about the rrd-users