[rrd-users] rate per day graph from rate per hour DS
griffithba at gmail.com
Tue Jan 30 22:32:27 CET 2007
On 1/30/07, Alex van den Bogaerdt <alex at ergens.op.het.net> wrote:
> On Tue, Jan 30, 2007 at 01:07:30AM -0500, Ben Griffith wrote:
> > I could try updating more frequently. I think I'd have to
> > adjust the rate multiplier accordingly. So if I update every 15 seconds
> > have to multiply by 900 (number of seconds in an hour divided by the
> > of 15 second blocks in a minute) instead of 3600 to get the number of
> > minutes the boiler was on in an hour.
> If you feel a minute to be close enough, by all means keep it this way.
I thought about it some more and decided it would be a good idea to collect
at a smaller interval, and still report in minutes. So I'll probably change
it to collect every 10 seconds, which means I'll multiply by 600 to get the
number of minutes per hour.
You are currently updating with "1" for an entire hour on, "0" for an
> entire hour off, and anything inbetween for a mix.
> If the boiler is on at the start of a new hour, stays on for another
> 15 minutes, switches off and stays off during the rest of the hour, I
> expect a number around 0.25/3600 in your database. Is this correct ?
In fact, it isn't. It shows 15/3600.
When you look at your data (dump it, or fetch from it) you should see
> numbers between 0 and 1/3600 (0.0 .. 2.7777778E-04).
Yesterday between 3 and 4am the boiler ran for 15 minutes. I fetched
yesterday's data and the entry from 4am was:
which is 15/3600
30 minutes of run-time between 6 and 7am looks like this:
equal to 30/3600
So the data is stored as numbers between 0 and 60/3600.
>> Your step size is 3600 seconds. Each minute you add another portion
> > >of the hourly statistics, I think using an averaging computation.
> > >(not 100% sure, but pretty sure)
> > Doesn't it just add up all the entries to get a total for the hour, then
> > from that a rate per second? Or does it actually compute the rate
> > throughout the hour, on the fly?
> I'm not sure what it does for "absolute". For "counter" it saves
> the value multiplied by time, and at the end (when the PDP is moved
> into an RRA) dividing by total time results in a rate.
I think the only difference between absolute and counter is that absolute is
assumed to be reset to 0 on every read. So where a counter would read
1,3,7,7,9, an absolute would read 1,2,4,0,2. In both cases, assuming all
five values were collected in the same interval, the stored value would be
9/stepsize. One of the tutorials points out that an absolute "stores the
current value divided by the step interval." Since I'm updating more than
once per step, in my case "current value" would be replaced by "sum of all
the values submitted during the step interval," I think. The same tutorial
says a COUNTER "will save the rate of change of the value over a step
period." I guess that would be the difference between the last value in
the current step and the last value in the previous step, divided by the
That's the same as what you said, except for the "multiplied by time" part.
Try, in parallel with your current setup, to update another RRD using
> GAUGE. You should end up with numbers like 0.25 (not divided by 3600)
> which mean the boiler was on during a quarter of the interval (whatever
I tried this and have two step intervals collected now. The first is a
partial interval, since I started some minutes after 2pm. The boiler was on
for 22 minutes, according to the ABSOLUTE RRD. The GAUGE RRD shows a value
of 5.6943858168e-01, but that's probably telling me the percentage of time
the boiler was on since collection started, partway through the interval.
During the second inverval the boiler was on for only two minutes and the
GAUGE shows 3.3333333333e-02, which is 2/60. The step interval is still 1
hour, and updates are still happening once per minute. If I understand
correctly, the result would still be the same (disregarding differences in
accuracy due to sampling rate) no matter how frequently I update the gauge,
unlike with the absolute. In fact, does the sampling rate even need to be
I guess I've still got some more experiments to try.
Thanks again for your help.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rrd-users