[rrd-users] How to get MAX/MIN of non-rates?

[Alex van den Bogaerdt]

>> > > It appears the CF for MAX doesn't apply to values within a period, 
>> > > but
>> > > only
>> > > when periods are consolidated into longer periods.

CF stands for Consolidation Function, so it makes sense it applies when 
consolidating the data.


>> > In other words: instead of step==300 and steps_per_CDP==1, you set 
>> > step==1
>> > and steps_per_CDP==300.
> I've just tried it in a test setup, and it works perfectly. Of course,
> I also needed to scale up the steps per CDP by 300 for the longer-term
> RRAs in the file too.

Correct.

And you will probably have different RRAs which span the same amount of time 
at the same resolution, but with different CFs.  (If not: you should.) These 
also need to be scaled to span the same amount of time per row.

> One question, just out of interest: when an RRD file is defined with 
> multiple
> RRAs of different resolutions and time durations, are the lower-resolution
> RRAs calculated using the data from the higher-resolution ones, or are all
> of them calculated independently, from just the input values as they 
> arrive?

Short answer: the latter.
Long answer:

It has been a while since I looked at this, but I seem to remember the 
following:

Data comes from your input and is transformed into a rate. If the data type 
is GAUGE, you are already giving it rates, so this part will be a no-op.

Then the rate is normalized, so that it fits inside a standard timeslot. You 
have set that timeslot to 1 second now. I'm not sure what happens with time 
"N" in relation to sub-second precision; if so desired you could use 
timestamps such as "1364918323" and then normalizing will also be a no-op 
for sure.

Then each of the RRAs gets a copy of this normalized timeslot, or timeslots 
if your update spans more than one update period. This is where the CDP_PREP 
area comes into play. As soon as there are enough updates received, thus as 
soon as one (or more) CDP timeslot can be filled, it happens.

Each RRA has its own preparation area. When you changed step==300 into 
step==1, RRDtool does need to do more work, for each of the RRAs (300 times, 
and again multiplied by the number of RRAs). This is the price to pay. If 
performance is seriously harmed by this (I doubt it, unless you have a very 
large number of RRDs with many RRAs) then the solution will be more or 
faster hardware, or reconsider your change.