[rrd-users] Re: Fup: About logging the REAL value (fwd)

[Alex van den Bogaerdt]

Tobias Oetiker wrote:

> as to the other point raised ... rrdtool at the moment assumes that
> the GAUGE measured value has NOT changed since the last sample ...

Indeed.  However, the averaging involved in that same rrdtool assumes
that the average should be stored in the RRA.  This implies a linear
growth during the sample period.  This is okay for averages (better yet:
it is the only proper way).  For other consolidation functions, averaging
may be wrong.

Another problem:
The assumption is made that this value is valid until the update.
This is not (always) true, it can also be valid from this moment on.
Again, this is something that can be fixed either in the front end
or in the back end.  If it has to be done in the front end, the
program should remember the current value or the delta while storing
the previous value in stead of the current value.  Next update, the
current value should be fed to RRDtool.

Unless I'm mistaking, RRDtool has been written with the problems of
MRTG in mind.  MRTG was written with counters in mind,  RRDtool should
also be handling other data sources properly.

For digital counters, the increase is per definition 1 or 0.  Therefore
min and max *have* to be made from averages to be useful.  Therefore it
is okay to be inaccurate or else min and max will always be 0 and 1.
Averaging here is similar to variable pulse width modulation.

For other datasources, such as modems in use, the value is built from
the addition of several bits.  While each modem apart will either be
in use or not, it is not a valid assumption that there is a point in
time where it will be true that the total is either 0 or 1.
Therefore there is no need to be inaccurate and averaging should not
occur when min and max are involved.  For the average number of modems
in use, averaging should occur or else an inaccuracy is introduced.

> now here one might want to introduce a different data source type
> where we assume that the Gauge value has grown linearly since the
> last sample ... but then again, since it all becomes a very small
> difference once you choose an apropriate sample rate to the problem
> I don't think it is worth the effort and the confusion ... 

Suppose that updates to the database are not (only) time triggered
but (also) event triggered.  The sample rate (if this is still
appropriate to name it like this) does not need to equal the highest
resulution that RRDtool can handle (currently 1 second, but see TODO)
provided that interpolation doesn't occur.

<imho>
For event triggered updates, perhaps with a timer to force an event
when there really is nothing to update except the heartbeat timer,
it would be better to have another behaviour in RRDtool:
- the value inserted is valid from insertion until the next update
  (currently, it is valid from the previous one until the current one)
- the interpolation does not occur; the RRA will contain the inserted
  value (currently, if an update occurs somewhere in the interval but
  not on a boundary, the value in the RRA will be neither the previous
  nor the current value)
</imho>

Question to Tobi:  is the next part correct?

There is a partial work around for these problems.  It does fix the
averaging before max/min.  It does not fix the "valid until" versus
"valid from" problem.

As long as RRDtool has a maximum resolution of 1 second the work around
for this problem is to have an 1-second step time, an heart beat counter
of (say) 600 seconds, an RRA with step==1 rows==600 for each CF and the
normal RRAs needed to do the job (for instance, step==300, rows==600).
The updates should occur no more than 600 seconds apart but need not
occur every second.

regards,
-- 
   __________________________________________________________________
 / alex at slot.hollandcasino.nl                  alex at ergens.op.het.net \
| work                                                         private |
| My employer is capable of speaking therefore I speak only for myself |
+----------------------------------------------------------------------+
| http://faq.mrtg.org/                                                 |
| http://rrdtool.eu.org  --> tutorial                                  |
+----------------------------------------------------------------------+

--
Unsubscribe mailto:rrd-users-request at list.ee.ethz.ch?subject=unsubscribe
Help        mailto:rrd-users-request at list.ee.ethz.ch?subject=help
Archive     http://www.ee.ethz.ch/~slist/rrd-users
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi