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

[BAARDA, Don]

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

	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

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