[rrd-users] Dynamic Steps

Alex van den Bogaerdt alex at vandenbogaerdt.nl
Mon Apr 22 01:10:04 CEST 2013

----- Original Message ----- 
From: "Oliver Loch" <grimeton at gmx.net>
To: "Alex van den Bogaerdt" <alex at vandenbogaerdt.nl>
Cc: <rrd-users at lists.oetiker.ch>
Sent: Sunday, April 21, 2013 5:43 PM
Subject: Re: [rrd-users] Dynamic Steps


Am 20.04.2013 um 11:17 schrieb Alex van den Bogaerdt 
<alex at vandenbogaerdt.nl>:

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

> Using the same timestamp again gives me an error. This is what I did:

update _them_ using the same timestamp_S_.
I am not saying that you should update one rrd using the same timestamp over 
and over again. I am saying that you should update two databases with the 
same data and the same timestamps, to compare what's happening. So for any 
given timestamp, you use that timestamp to update both databases, the only 
difference being the number 3600 or 1 used as the value stored.

> The joules thing is something you started to talk about. Not really my 
> problem. And I know that I get 3600W/h when I have one watt/hour per 
> second. Its simple math, but at the moment it doesn't seem to be possible 
> to update multiple times per second.

Yes, I did the suggestion you store Joules per second, instead of some 
archaic unit, in the hope that it makes life easier for you later.

Simple math, but you seem to get it wrong. It's watt * hour, not watt / 
hour. If you want to store Wh instead of J, fine. RRDtool will do it, no 
problem. After a couple of weeks/months/years when you want to see a graph 
in Watt over time, you will have to multiply your data by 3600 using a CDEF. 
Still no problem, as long as you understand what rates are in your RRD.

And yes, it is possible to update multiple times per second, just not with 
the same timestamp. Tobi replied about this recently, please see his post.

You replied with a question about having to update 14400 (or something like 
that) instead of 3600, which just is not true. Just update with either 3600 
if you follow my recommendation, or with 1 if you like Wh, everytime you get 
a 'tick'. So so multiple times a second if you have to.

> So just for my understanding: If I want to have an RRA that holds the 
> daily average of the power consumption over a month, I need to create an 
> rrd with 86400 PDPs? And If the average should be covered on a weekly 
> basis over a month, I'd need an RRD with 7*86400 steps and it needs to be 
> created like this:

> rrdtool create test.rrd -s 1 DS:some-input:ABSOLUTE:14400:1:15000 
> RRA:AVERAGE:0.5:604800:52

> ?

*if* the step size is one, yes, except that your RRA stores weekly data for 
a year, not a month (maybe that's a typo?)
If you set your step to some other value, you will also need to change the 
number of PDPs per CDP.
The number of seconds covered by every CDP is simply the product of step and 
steps, so 1*604800 will work, as will 60*10080, and 300*2016.
If you care only about averages, there is no need to have a low step 
setting. If you care about maximum/minimum, then do set your step low.

Maybe you are aware of this, maybe not: you will not get 
midnight_to_midnight days, and not start_of_monday_to_end_of_sunday weeks. 
CDPs start and end on a whole number of {step*steps} seconds. Days run from 
midnight UTC to midnight UTC, which is 2am to 2am currently in europe.

> I know how normalization (standard score) works. It's not black magic to 
> me. But the question if writing multiple values to the database per second 
> then leads to a max value in the PDP or to the average in the PDP (yes, 
> the PDP, multiple updates per second -> normalization -> PDP), hasn't been 
> answered till now. Asking again then lead to your statement that it would 
> be better to multiply the value outside rrdtool first and then write it to 
> rrd.

I never intended to relate multiple updates per second to multiplying input 
values outside RRDtool.

The data collection phase, when you feed your updates to RRDtool, do not 
keep track of minimum, maximum, average or last. That is a property of the 
consolidation phase (phase 3).

> Facing the fact, that it doesn't seem to be possible to update multiple 
> times with the same timestamp, I'd say that either I'm missing something 
> (timestamp with mili-/microseconds perhaps?) or that something else 
> doesn't seem to work. Again: that's why I'm asking for it here.

Tobi replied on april 17 how you can specify timestamps with a decimal 

More information about the rrd-users mailing list