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

Thu Aug 24 06:51:00 MEST 2000

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

*> G'day,
*> 
*> last comment before I do some work :-)
*> 
*> > -----Original Message-----
*> > From:	Tobias Oetiker [SMTP:oetiker at ee.ethz.ch]
*> > Sent:	Thursday, August 24, 2000 6:43 AM
*> > To:	Jakob Ilves
*> > Cc:	Alex van den Bogaerdt; RRD users
*> > Subject:	[rrd-users] Re: Fup: About logging the REAL value
*> > 
*> > 
*> > Today you sent me mail regarding [rrd-users] Re: Fup: About logging
*> > the...:
*> > 
*> > *> So doing interpolation of data to get 5 min samples is fine for me as
*> > *> long as it is intended only for AVERAGE calculations and not MAX
*> > *> calculations.
*> > 
*> > I see ... we are not done yet ... there is no such thing as a MAX
*> > in a 5 minute interval. If 5 minutes is your resolution you can not
*> > see more than the 5 minute  averages ... else you are not doing 5
*> > minute intervals ... if you can see into the interval then you are
*> > doing a different resolution lets say 30 seconds ... you thus have
*> > to configure the rrd database acordingly and you will get the
*> > higher resolution ...
*> > 
*> 	Yes, the way rrd currently works the minimum resolution is the
*> "step". However, the code already correctly accumulates and calculates
*> averages from multiple samples in a single step. It would a small (logical)
*> step to also record MIN/MAX/LAST values from multiple samples in a single
*> step.
*> 
*> 	This would make the minimum consolidated/stored resolution the
*> "step", but the minimum sample resolution would be the sample rate (which
*> could be higher or lower than the step). I haven't looked at the code to
*> check if this is easy or not, but it could also make it meaningful to have a
*> "heartbeat" less than "step".

the whole point of the exercise is that "step == samplerate" and
thus the whole averaging which happens during one step is only
threr to compensate for the inability to catch your values at the
appropriate sample rate ... 

If you implement you  proposed MIN / MAX cf then you will always
have a preceived sample rate of 1 second only that your sample rate
is not realy 1 second ... an important parameter in rrd is the
minimal required heart beat ... for a sample interval of 1 second
we would set this to about 2 seconds (analog to the 600 seconds for
a 300 second interval) .. unfortunately you will not read out your
probe every second and thus the a unkown MIN / MAX at the end ...

If you realy are able to sample every 2 seconds, then go ahead and
set --step 2 and feed your data into rrd ... no need to have a RRA
at the 2 second resolution ... your RRD can have 300 second
resolution and you can have one for AVERAGE and another ones for MIN
and MAX they will faithfully record your MAX 2 second average ... 

as to the other point raised ... rrdtool at the moment assumes that
the GAUGE measured value has NOT changed since the last sample ...
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 ... 

cheers
tobi

*> 	Whether you want to do this or not is another question. Currently
*> you can already get the behaviour you want by setting "step" to your desired
*> resolution. The only possible benefit would be some reduced storage, and
*> perhaps reduced overheads from less rotation of that storage. The other big
*> problem is your sample period becomes variable, making MIN/MAX/LAST
*> meaningless for COUNTERs, unless you do logically weird stuff like change
*> the resolution from the (high but variable) sample rate to the (lower but
*> fixed) "step" when CF'ing MIN/MAX/LAST RRA's with "steps>1".
*> 
*> 	Actually, can you have an RRD _without_ a RRA with steps=1? That
*> might also be a way to avoid high resolution storage overheads with a high
*> resolution "step".
*> 
*> 	[...]
*> > *> 2.) I don't consider adding these two DSs to complicate the user
*> > *> interface to rrdtool very much.
*> > 
*> > it would not
*> > 
*> 	This is where implementing MIN/MAX/LAST CF's for an RRA with steps=1
*> is cleaner. Currently these CFs are only meaningful when steps>1. Adding
*> this functionality simply makes them meaningful in all cases (well, except
*> for non-GAUGE DS's, where the resulting values would be meaningless).
*> 
*> 	[...]
*> > *> 4.) It does not mess with the data.  It just picks another
*> > interpolation
*> > *> strategy which in some circumstances provide more accurate data to the
*> > *> end users.
*> > 
*> > correct ... and it will further confuse the users who seem to have
*> > a hard time grasping the concept as is stands ...
*> > 
*> 	:-)
*> 
*> 	ABO
*> 

-- 
 ______    __   _
/_  __/_  / /  (_) 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