Thanks for your help! Tony
In article <57A1D4E203734E218387B2DC65C8FAF5@DESK>, Alex van den Bogaerdt <a...@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@lists.oetiker.ch > https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users > -- Tony Mountifield Work: t...@softins.co.uk - http://www.softins.co.uk Play: t...@mountifield.org - http://tony.mountifield.org _______________________________________________ rrd-users mailing list rrd-users@lists.oetiker.ch https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users