[rrd-users] Re: Avoiding pitfalls when using GAUGE with some kind of data

Serge Maandag serge.maandag at staff.zeelandnet.nl
Tue Aug 24 11:53:04 MEST 2004


> You are not taking into consideration the content of the 
> email you are replying to.

I was, but IMHO it all boils down to the misconception I still
Feel is present.

I can understand why it would be more convenient to you if rrdtool
Did behave the way you'd like it too, but you are trying to make a
Horse bark. So far the only one barking was Alex :)

It would be a big break with the way rrdtool logically works and 
IMHO the functionality isn't necessary. To me rrdtool is giving
me the best representation of the average value of a sampled series
of numbers. I can sample it at a granularity of 1 second or at a 
granularity of 12 hours and at the end of the day the overall average
will be the same and statistically correct for both methods.

> Your answer is mixing all my previous emails and is not 
> adding anything new to the discussion, I'm afraid.

If I don't agree with you, I see no reason to add fuel to the
discussion. I mearly point out why I think rrdtool is doing the right
thing.

> In my last mail I show it gives very strange results already, 
> for some kind of data.
> Show me the "bus stop" example is flawed and I will agree with you.

It isn't, but neither is the interpretation of the input by rrdtool to
me.

> Most people are plotting "complete functions" of time (not 
> sure about the technical term), so resampling is a good thing 
> for them. The remaining people are either plotting slightly 
> incorrect graphs without even realising it or they are lucky 
> enough to always insert values step-aligned. Or they just 
> don't use RRDtool because it doesn't work for them. I'm a 
> lucky one. Or I might just be wrong, which is the reason why 
> I'm writing to the list hoping someone could open my eyes.

I'm trying to, but I'm not sure we can agree.
Rrdtool eats rates and if gauges are used, it's mostly rates that
have been pre-normalized. In your cases the problem is that you are
updating with multiple values within a step interval. In the case of
gauges rrdtool behaves like this:
- if one update is made anywhere within the step interval, it is
  extrapolated to the next step border.
- if multiple updates are made within the step interval, rrdtool
  considers it as if you chose a step size that is too course.
  It re-normalizes the data by taking weighted averages, which
  is the most sane solution, IMHO.

In case I wanted to have the functionality you are needing, I'd
be happy to calculate the "simple average" myself in a cache and 
to update it on the step border.

Your wish resembles the wish of some people that want rrdtool to
behave like an SQL database, they want to input data anywhere within
the step interval and want to see those exact numbers when doing a 
fetch. I don't agree with them either.

Rrdtool is all about rates. Other input is possible, but need some help.

> >Setting the step size to 1 second will give you the output you want.
> >Aligning your updates to the step interval will do that too
> >
> This was first pointed out by Alex and I agree on it, even if 
> I felt it was sort of a hack. But this is a different case.

I figured you mist his point, since you did not react.
Given the uglyness of the discussion I can understand that, though.

Serge.

-------------
Op de inhoud van dit e-mailbericht en de daaraan gehechte bijlagen is de inhoud van de volgende disclaimer van toepassing: http://www.zeelandnet.nl/disclaimer.php

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



More information about the rrd-users mailing list