[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