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.
Correct > 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 rrd-users@lists.oetiker.ch https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users
