[rrd-users] Re: disabling interpolation?
don.baarda at baesystems.com
Thu Aug 24 03:22:13 MEST 2000
> -----Original Message-----
> From: Rainer.Bawidamann at rz.uni-ulm.de
> [SMTP:Rainer.Bawidamann at rz.uni-ulm.de]
> Sent: Wednesday, August 23, 2000 8:20 PM
> To: rrd-users at list.ee.ethz.ch
> Subject: [rrd-users] Re: disabling interpolation?
> In fact you need the information "maximum of number or users
> simultaneously logged in since x" where x could be the last time this
> information was queried. Now a DST of REAL would be useful.
> If you don't have this information (from a radius log e.g.) you should
> use the "average maximum" numbers from rrdtool and explain the odd
At this point I was about to discuss the implications of special
GAUGE sensors that accumulate and "pre-adjust" data continuously to give rrd
min/max/mean/median whatever since the last sample. However, the more I
thought about it, the more complicated it got.
There are two slightly different types of GAUGES. In one, it simply
returns the current value when sampled. In another, it returns a summary
(typicaly an average) since the last sample. This is similar to the
difference between a COUNTER and an ABSOLUTE. Lets call them VALUE and GAUGE
(reason for the names becomes clear later on). The correct way to calculate
the "area under the curve" for GAUGE is;
pdp_new[i] = atof(updvals[i+1]) * interval
and for VALUE it would be;
pdp_new[i] = atof( updvals[i+1] + updvals[i] )/2 * interval
(NOTE: these use variables as found in the code... /src/rrd_update.c
The actual code uses the calculation shown above for GAUGE. This
might have implications for people wanting mega-accurate rrd's using GAUGE,
but note that the difference is very subtle and approaches zero as your
sample rate gets higher. Note that VALUE type sensors (instantaneous sample)
are useless if your sample rate is not high enough for the change rate of
the data. However, GAUGE type sensors (average since last sample) can be
useful even at low sample rates.
All of this becomes pretty academic, because as long as you sample
at a high enough rate, there is no difference. Currently this applies in
general with GAUGE... the faster your sample rate, the more meaningful your
data will be... particularly if you have a VALUE type sensor. For meaningful
MIN/MAX you also want to make your step interval small.
The more I think about it, the more sense it makes to have MIN/MAX
CF for an RRD of a GAUGE with steps=1. You go to heaps of effort to
calculate accurate averages for multiple samples in a single step, why not
also get MIN/MAX? I know it is meaningless for COUNTER, but for GAUGE it
would mean you could use a large step and still get a pretty accurate MAX
using a high sample rate. A special sensor that returns the maximum value
since the last sample would even give you a true max.
I've looked at the code, I've seen others comments, and I think
implementing MIN/MAX CF's for steps=1 is cleaner than introducing new
OMAX/OMIN DS's. I think I could even do it quite easily. However, I don't
need it and don't have the time, so I'll leave it as an exercise for those
who do :-)
Unsubscribe mailto:rrd-users-request at list.ee.ethz.ch?subject=unsubscribe
Help mailto:rrd-users-request at list.ee.ethz.ch?subject=help
More information about the rrd-users