> So you feed in the number 7 after a one day interval. The program > computes the rate as 7 / 86400 <somethings>/second and stores that - > assuming you update on a step boundary. > > If your updates are not exactly on the step boundaries then the > program will normalise what you feed it to fit. For example, if you > do updates at half-time (ie 12 noon), then each stored sample will be > 50% from one update, and 50% from the next. If you update at 6am, > then stored samples would be 75% from one update, 25% from the next. > > In your case I think it's simply a matter of scaling. You can either > multiply what you feed in by 86400, or you can multiply what comes > out by 86400 when you come to graph it.
I recommend against scaling the value in this way. The GAUGE data source type is exactly what you are looking for here. With GAUGE (instead of ABSOLUTE) the data provided to rrdtool update is treated as a rate (units are 1/s) and it is stored in the database as is (without being divided by the time period). Note: if the updates are not made on 24-hour boundaries (12 midnight UTC), then Simon's comments about normalization still apply. The important thing to realize about rrdtool is it is meant for data __consolidation__; it is intended for archival of trend data. The most typical use is when you need different resolutions for different time periods (every 5 minutes for the past two days, every 30 minutes for 30 days, every 6 hours for 1 year, etc). If you need to store a tuple (time + data value) and retrieve exactly that tuple at a later time, rrdtool is NOT for you. rrdtool is not inaccurate, but it does consolidate data, so you generally cannot retrieve the exact value you inserted. -Sam _______________________________________________ rrd-users mailing list rrd-users@lists.oetiker.ch https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users