Please just do some experiments with fake data. Create two databases with the same property, ABSOLUTE counter type. Update them using the same timestamps (do not use "N"), four times a second, and make sure there is enough data to fill a couple of timeslots in your RRA.
Feed 3600 into one RRD every time, feed 1 into the other RRD every time. You should see a rate of 14400 in the first, and 4 in the other. Now use a CDEF to multiply 4 by 3600, and you get 14400 again. Same resulting rate, other way to achieve it. The resulting databases have Joules/second in the first, and Wh per second in the other. That CDEF transforms Wh into J, because 1 Wh is just 3600 J. Do not confuse this with another reason to multiply by 3600. You have been asking about 'per hour' rates. If you have 1 Wh per second, constantly, then after an hour you will have used 3600 Wh. So if you multiply a rate by 3600, you get 'rate per hour' instead of 'rate per second'. If your database contains Wh, and you want to know Joules/hour, then you need to multiply by 3600 twice (or one time by 12960000, for performance reasons). And to answer your question about where RRAs get their data: it is already described. PDPs are used to build CDPs. See the three phase description again. If RRAs get their data from other RRAs, it would have been described there. Really, you are thinking and assuming a lot, but you do not verify this by experimenting. Start simple. Step==60 (meaning: every step is 60 seconds). Update with timestamps that are a whole multiple of 60 (n*60). Start simple with three RRAs, one using 1 PDP per CDP, one using 2 PDP per CDP and one using 3 PDP per CDP. See what happens, and when it happens, by examining the resulting RRD every time between updates. Later you start updating with timestamps that are not a whole multiple of 60 seconds, e.g. at n*60+10, and you learn about normalization. Try updating a couple of times per step (e.g. every 15 second, n*15), try updating less than one time per step (e.g. every 5 minutes, n*300). Play with the heartbeat setting when you do this. Set it to 600 in one of your experiments, and set it to 60 in another (with all other parameters and updates being equal). Why does your data become unknown? You do not need to ask, because you will know. There are many other experiments to think of. Whenever the result are not corresponding with what you believe to be true, chances are your beliefs are incorrect and you should experiment further and read more manual pages. I'm not saying there are no bugs in RRDtool, but the topics we covered are used by so many people that I think bugs if any have been found and solved already, a decade ago. ----- Original Message ----- From: "Oliver Loch" <grime...@gmx.net> To: "Alex van den Bogaerdt" <a...@vandenbogaerdt.nl> Cc: "Alan Finlay" <alan.websit...@chankly.com>; <rrd-users@lists.oetiker.ch> Sent: Friday, April 19, 2013 6:43 PM Subject: Re: [rrd-users] Dynamic Steps Hi, > 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". > How could that be done with an CDEF? Let's assume the W/h example. As far as I understand it and based on the information in your e-mail, the CDEF language only works with CDPs. So if there is a CDP every second, and the CDP - steps can't be below one second, multiple ticks per second would be used to calculate the average of the CDP-step and stored in that particular CDP. So imho trying to solve this via CDEF wouldn't work as we already lost the exact data that we'd need to calculate it. Only thing I could think of would be to add more steps per second (which isn't possible) or trying to use more CDP per hour. Like 7200 which would give me "CDP Steps" at the range of 0.5s. But as this isn't possible one idea could be to just "jump" multiple steps per second and use that information later when creating the graph. E.g.: Four "steps" per second would give me 14400 steps per hour. So every second stuff is written to a CDP it just forwards four steps instead of one. and only fills as much steps as there were ticks. So four CDPs per second, three ticks that second, it moves forward 4 CDPs and then fills the last three. But I also have another question that isn't really clear to me: Let's assume again that I'm monitoring the power meter. The database has one source, which is the "tick"-counter that has 3600 steps and uses the ABSOLUTE counter. Now I add multiple RRAs. First one is for an whole hour with an per minute average. So I store 60 CDPs that are created with 60 CDPs from the datasource. Now I'm also creating an RRA that holds the average per hour and requires ??? CDPs to populate one CDP. The question is - if defining multiple RRAs, are they all referencing the main data source or are RRAs that store data over a long time, less exact, referencing to the "smaller" RRA? So. what happens if I have 3600 steps per hour and the only RRA does the average of two hours? Is rrdtool smart enough to handle that? KR, Oliver _______________________________________________ rrd-users mailing list rrd-users@lists.oetiker.ch https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users
