humke <arjan.hum...@gmail.com> wrote:
> I can see where you are going with this. I want the total surface of 24 bars
> to be the same as the surface for the 1 bar. So AVERAGE would be the correct
> CF choice here, because only that CF would give me the same surface. I will
> try this.
> I could (or maybe even should) still use LAST for the highest resolution
> (one hour) in this case right? As it's one PDP or are all my 10 second tries
> to store the value also CF'ed?
What is your step size - that has a large impact on what you need t put in and
what you get out.
If (for example) your step size is one hour (for the gas), and you ask for data
with a resolution of one hour, **AND** you have put in data exactly every hour
ON THE HOUR - then you'll get out what you put in (barring rounding errors and
conversion from counter to rate).
If you remove the "on the hour" bit of that, then what you get out will be
different to what you put in. So say your meter gives you data timestamped at
20 minutes past the hour, each one hour slot within the RRD will comprise 1/3
of one value plus 2/3 of the next value. Ie, to give you a value for the slot
from 12 noon to 1pm, it'll use 1/3 of the value from 11:20 to 12:20 plus 2/3 of
the value from 12:20 to 13:20 - and you will not see any data (it'll return as
NaN) for that slot until the 13:20 data is entered.
Consolidation functions have no effect on this as this is the standard
normalisation to map the data you put in to the primary data points (PDPs)
defined by your step size.
Updating more often than the step size doesn't really change this - all the
interim data is just accumulated up until you pass the next step time and the
PDP is complete. So the above example is modified a bit. Assuming that the data
actually only changes at 20 minutes past the hour, if you updated (using the
same counter value) every minute, the 12:00-13:00 PDP could be completed as
soon as 13:00 (if you update "on the minute") or at the latest by 13:01.
This would give you different values though.
Assuming usage was zero beforehand, 3600 units registered in the 12:20 update,
and 7200 units registered in the 13:20 update.
Updating hourly with the data timestamp will give usage for 12:00-13:00 of 1.67
units/s (1/3 x 3600 + 2/3 * 7200). If you update every minute on the minute,
all the 3600 units would appear to have been used between 12:19 and 12:20 with
zero for the other 59 minutes. At 13:00, RRD would "close" the PDP, average the
3600 units across the hour, and arrive at a value of 1 unit/s.
In reality, neither value is right, and neither value is wrong ! You might have
been (for example) running the shower (and hence burning plenty of gas) before
12, or after 12, and using nothing at other times; or you might have had the
heating on, and burned the same amount of gas at a steady rate during the whole
hour - but the meter won't tell you. Just like the example Alex uses in his
tutorial - you might have driven slowly for an hour, or driven like a lunatic
for part of the time and stopped for a coffee, in either case the odometer will
only tell you total distance travelled unless you read and store the values at
Now, what does the CF do to this ? Actually nothing ! If "a" is a simple
number, then min(a)=avg(a)=max(a)=last(a). However, if "a" were a set of
numbers 1,2,3,40,4, then min(a)=1, avg(a)=10, max(a)=40, and last(a)=4
In my experience, LAST as a CF is only of use for printing in the legend to
show the last value on the graph, or rather, the last value that went into the
last CDP shown on the graph. So taking those numbers I just used, you could
have a column on the graph (assuming you are using a consolidation of 5 PDPs
into one CDP) that's 10 units high, and assuming no larger values, last would
So if you have a step size of 1, and graph hourly data, the consolidation
function used is effectively a null operation - assuming you have a CF
consolidating 1 PDP into a CDP !
> I do need to read the tutorials again, because I am getting all these
> questions about stuff I thought I understood.
To be fair, there's come fairly complicated stuff going on there, it does take
some getting your head around.
rrd-users mailing list