[rrd-users] Dynamic Steps

[Alex van den Bogaerdt]

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 
reasons).

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 
there.

Really, you are thinking and assuming a lot, but you do not verify this by 
experimenting.

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


Hi,

> 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 
CDP.

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 
three.

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?

KR,

Oliver