humke <> 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 
frequent intervals.

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

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

Reply via email to