>> > > 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 [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users
