[rrd-users] how to calculate the sum of a DS

Alex van den Bogaerdt alex at vandenbogaerdt.nl
Thu Jul 4 10:03:18 CEST 2013


----- Original Message ----- 
From: "stefan" <Stefan.Bruder at gmx.net>
To: <rrd-users at lists.oetiker.ch>
Sent: Thursday, July 04, 2013 8:51 AM
Subject: [rrd-users] how to calculate the sum of a DS


> Hi,
> I am struggling on a problem calculating the sum of a DS for the given
> period.
> I have a rrd:
> rrdtool create PV.rrd --start now --step 10  DS:PVWatt:GAUGE:60:U:U
> RRA:MAX:0.5:1:60480
>
> the PVWatt has values from 0 to 5000
>
> I want to Print to total amount of PVWatt for the given time period (24h)

Which is why "TOTAL" exists...
http://oss.oetiker.ch/rrdtool/doc/rrdgraph_rpn.en.html
VDEF:total=mydata,TOTAL

If it doesn't work, if it produces something completely different than you 
expect, then either TOTAL has a bug or your setup does.

When processing things like this, it's easy to confuse W, kWh, J. That's why 
my money would be on a bug in your setup, not on a bug in TOTAL.
Also, you are using MAX. Not good. I think you need averages.

To debug your database setup, it's input, it's output:  the total of all 
rates shown in 24 hour graph should equal the average of those values, 
multiplied by the amount of time (86400 seconds in your case).

See:  the average of 1,3,2,8,4,3,9 is computed by taking the sum: 
1+3+2+8+4+3+9=30 and divide that by the number of entries, 7. The average in 
this example is 30/7.  If I know the average, and if I know the number of 
entries, I can multiply those to end up with the total: (30/7)*7=30.
I can compute the total if I know the average, and the amount of numbers 
used to make that average.

Same for you. If your database contains Watt per second (which does not 
really make sense, but please see two paragraphs later) and if you graph 24 
hours (which is 24 * 60 * 60 = 86400 seconds) then the total is the average 
of  "Watt per second", multiplied by 86400.

As there (currently at least) is no way to do RPN calculations on VDEFs, you 
cannot get the average and multiply that by 86400.  But taking the average 
of something already multiplied by 86400 gives the same result, so multiply 
your rates by 86400 and take the average of that.

DEF:Watt=PV.rrd:PVWatt:MAX
CDEF:Watt_times_86400=Watt,86400,*
GPRINT:Watt_times_86400:AVERAGE:%6.2lf

Note about Watt per second: it sounds stupid, but technically speaking it is 
what is in your database.  It is similar to using RRDtool to store and graph 
temperatures, technically speaking we would be storing and graphing 
temperature changes in degrees per second.
BUT, as long as you understand that you achieve the goal by lying to 
RRDtool, there is no problem to feed it Watt, and make it believe it is Watt 
per second (which is what GAUGE means: "this is already a rate", i.e. this 
is already Watt per second).

However, in case of Watt, which is Joules per second, I am always tempted to 
suggest that you use an ABSOLUTE counter, feed Watt, and end up with a 
database which stores Joules per second.

Make sure you fully understand what kind of number you are getting and which 
you are storing in the database. And then also make sure you process it 
correctly.

Another example: suppose I am monitoring a simple value, on and off. I use 0 
for off and 1 for on.  And now suppose I am using the MAX consolidation 
function... over time, all zeros will have gone, I end up with ones only, 
and I lost all information.  That is because MAX(a,b) only results in zero 
when both inputs are zero, which is becoming more and more unlikely.
I can use MAX if I want to know "was there an error at any point in time" 
(where 0=no error, 1=error occured). But if I want to know the total number 
of errors during an interval, I really need to know the average number of 
errors per second, not the maximum.

"but i have only one RRA, no averaging taking place".  You are graphing 8640 
intervals of 10 seconds each, on 600 pixels. That's more than one interval 
per pixel column, so RRDtool will expand the time range a bit, and it will 
do on the fly consolidation of your data.  Both are bad for you.



More information about the rrd-users mailing list