[rrd-users] Counts per minute with ABSOLUTE

[Alan Finlay]

Hi RRD users,

 

Thanks Alex for your response below in a different thread (Re: [rrd-users]
Dynamic Steps).  I will start  new thread to avoid any further interference
with that thread.

 

You hit the nail on the head that I needed to understand that rrdtool stores
rates as a "per second rate".  That was the key concept I overlooked in my
understanding.  I knew rrdtool converted to a rate, but since I was
interested in counts per minute, I failed to notice it was counts per second
I should be storing in rrdtool.

 

My current approach to storing the counts per minute is using a GAUGE and
storing the CPM value in rrdtool as if it were counts per second. Hence I am
storing the value 60 time larger than it should be (or equivalently the
units are CPS/60).  That doesn't cause any problem as long as I am aware of
what I am storing (which I wasn't).

 

When I converted to using an ABSOLUTE data store I needed to understand that
I wanted counts per minute in the datastore, but was getting counts per
second.

 

Thanks again Alex for sparing the time to explain that.

 

Here is Alex's post for reference:

 

> Clearly you understand something I don't.  The value 0.366 is 22/60 I 

> take it?  But why should counts per second be stored?  The rrd db defs 

> are for a step size of 60 seconds, so I am expecting it to store 

> counts per minute.

 

Why? Because that is how it works. Always.

 

Three clearly different steps to process your input: 

http://rrdtool.vandenbogaerdt.nl/process.php

 

Maybe it would have been better to call these steps "phases" so to not
confuse step and step, but I'm not going to change it anymore now.

 

First phase: compute a rate from the input, using a set of rules such as
"GAUGE", "COUNTER" and so on. The value of "step" is not used here.

 

Result: a rate. {something} per second. Yes, even when using RRDtool to
store something like temperature, internally it is still handled as if it
was a rate. We get away with this because we lie about the input: using
GAUGE we are telling RRDtool the input is already {something per second} so
don't touch. As a result, this "rate" goes to the next phase.

 

Sorry for sidestepping. I just want to show: no matter what parameters you
use, it is ALWAYS going to be a rate of {something} per second.

 

We have a rate now, valid between the previous update and the current
update. RRDtool does not work (by design) with arbitrary time intervals so
this rate needs to be normalized into standard buckets of {step} seconds. 

And this is where, and for what purpose, {step} is used.

 

If you need higher precision, sample your input a lot (I mean: outside
RRDtool), update a lot, and have a small {step} value (e.g. one second). See
the web page I directed you to, the paragraph starting with "If you think it
isn't ....", the part about the red rate could be twice as high as sampled. 

If it is important to know the "real rate" (really only a better
approximation), for instance in the case of a MAX consolidation function,
then step should be really low *and* the input needs to be sampled often.

 

Another sidestep: when updating multiple times per second, it could be
useful to have {step} be smaller than one second. I don't know, and can
currently not find out for myself, if this is possible. Please fill me in.

 

The third and final phase is to build CDPs from PDPs, and store these CDPs
into an RRA. Even if you use 3600 PDPs of one second each, the resulting CDP
will still have a rate in {something} per second. This rate is just valid
during a whole hour.

 

This said, if you want to see "per minute" (or per hour, per 86400 seconds
for a day, per 604800 seconds for a week) then just multiply your input, or
the resulting rates, by the appropriate amount of seconds per unit you
choose. After all, 0.3666666666666.... {something}s per second multiplied by

60 seconds, results in 22 {something}s.

 

Although this is not a rule of some sorts, I prefer to keep the input 'as 

is', and do such multiplications in a CDEF:   CDEF:perminute=persecond,60,*

 

But in the case of Wh, I recommend to multiply 'ticks' by 3600 at input
time, because each tick is worth 3600 Joules, and this results in a clean
database storing Joules per second aka Watt. Although this could also have
been done in a CDEF, it just does not "feel right".

 

To prevent another problem: no, after multiplying by 60 (either at graph
time (CDEF) or at input time), the X-axis does not magically change. If the
amount of PDPs per CDP is low enough (e.g. 1), and the step (duration of one

PDP) is low enough (e.g. 10 seconds), and the amount of time shown on the
graph is low enough (e.g. 12 minutes), and the graph width is large enough
(e.g. 360 pixels wide), you can still see "something per minute" change a
couple of times during a minute. Using the example numbers I just gave, the
resulting graph will show 72 CDPs of 10 seconds each, using 5 pixels per
CDP. This results in a somewhat staircase looking graph.

 

Similarly you can tweak your settings so that each of the stairs shows no
less than 60 seconds, which would probably be a good idea if you use a "per
minute" view. Just make sure each CDP contains n*60 seconds worth of data. 

With {step} being equal to 1, this means you need 60 PDPs per CDP for a
minute, or 3600 PDPs per CDP for an hour, and so on.

 

Alan F.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.oetiker.ch/pipermail/rrd-users/attachments/20130421/724fb2ee/attachment-0001.htm