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

[Tony Mountifield]

Thanks for your help!

Tony

In article <57A1D4E203734E218387B2DC65C8FAF5 at DESK>,
Alex van den Bogaerdt <alex at vandenbogaerdt.nl> wrote:
> >> > > 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.
> 
> 
> _______________________________________________
> rrd-users mailing list
> rrd-users at lists.oetiker.ch
> https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users
> 


-- 
Tony Mountifield
Work: tony at softins.co.uk - http://www.softins.co.uk
Play: tony at mountifield.org - http://tony.mountifield.org