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

[Tobias Oetiker]

Today you sent me mail regarding Re: [rrd-users] Re: Fup: About logging the...:

*> 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.

assuming that the GAUGE value has been the same since the last
reading is as good as assuming that it changed linearly since the
last reading .. because we no nothing about the nature of change in
the value we are monitoring .... It is all about choosing the
proper samling rate ... 
*> 
*> 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.

see above

*> 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.

the proper thing todo with modems is to send an update to rrdtool
when ever there is a connect or a disconnect ... In the update you
specify the time of the connect or disconnect but the number of
modems in use BEFORE the event ... 

*> > 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.

if it is event triggered then it is not sampling ... rrdtool will
do its best to convert the data provided into sampling look alike
data in order to be able to work with it ... 

*> <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 inserted value could be stored ... until the next update ...
there is room for thin in the rrd format ... 

*> - 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)

no interpolation must occure all the same ... because rrdtool works
with sampled data and for data which is not sampled it tries to
convert it to sampled data ... 

cheers
tobi

*> </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,
*> 

-- 
 ______    __   _
/_  __/_  / /  (_) Oetiker, Timelord & SysMgr @ EE-Dept ETH-Zurich
 / // _ \/ _ \/ / TEL: +41(0)1-6325286  FAX:...1517  ICQ: 10419518 
/_/ \.__/_.__/_/ oetiker at ee.ethz.ch http://ee-staff.ethz.ch/~oetiker


--
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