# [rrd-users] Quantisation issues - how do i get the math right?

Simon Hobson linux at thehobsons.co.uk
Fri Mar 10 17:48:31 CET 2017

```Andreas Schuldei <andreas+rrdtool at schuldei.org> wrote:

> I just got an idea that there might be some confusion about the word "Power".
>
> I am interested in both the engergy (Energie) and the power (Leistung) output. Currently I am dealing with the power graph. Energy is the sum (or integral over time) of the power. So ABSOLUTE (implemented as an ever increasing staircase) would emulate the absorbed energy, but not the power.

Just to be clear, RRD **ONLY* does rates - so power flow. To get totals (ie accumulated energy) you multiply the rate (where appropriate, an averaged value) by time. SO whatever you feed in, you need to arrange that it's a rate.

In your case, I think you have no option other than to use the counter as it is, and either multiply or divide by an appropriate factor to get the power instead of some arbitrary number of "somethings".
In your case, I suspect the best you'll get is to store : flow rate (f) and treat the values you read as a counter, t1 and t2, and use derived/computed DSs for "t2-t1" (temperature difference) if that might be useful in future, and "f*(t2-t1)*k" (where f is the flow rate and k is the "fudge factor" to store actual power (energy flow rate). It's going to be very uneven due to the chunkiness of the data updates you can feed in - there isn't really anything you can do about that. Once you've done some aggregation (eg to daily figures) then this lumpiness should reduce. However, you will get false data for MAX values.

Simple answer - if you only get some data in big chunks, there's not much you can do to make it "not chunky". IIRC it's come up before, possibly in relation to a weather station and a coarse reading from a rain gauge.
The only other thing you could do is simply not look at fine grained data. If (say) on a typical day the counter might step (say) once in half an hour - then have your step at (say) 2 hours. You'll never be able to look at data finer grained than 2 hours. But your normalised data will vary between (say) 3 per 2 hours when flow is down, to (say) 6 per 2 hours when it's higher. Better than it doing zero, zero, zero, <some large number>, zero, zero, ...

But you will still want to feed in data fairly regularly, because you'll want the average temperature difference over each 2 hour period - assuming it varies significantly over that sort of timescale (eg clouds appearing/disappearing) then you don't want just a snapshot each 2 hours.

The other option is to change the flow meter to one giving a useful output !

```