[rrd-users] Re: Problem on update

[Alex van den Bogaerdt]

Chris Raymond wrote:

> Thank you for your explanation.  I understand that this design
> philosophy grew out of RRDtool originally being planned to meas-
> ure rates only.  However, I would argue that for single-point
> data type GAUGE RRAs, placing NaN into the intervening points
> makes the most sense.

But there are no "single-point data type GAUGE RRAs", at least
not as far as I know.

Consider this setup:

step==1
heartbeat=86400
T+0     I've entered 0 in the database because I received a trap
        saying a modem line became active
T+5000  I enter a 1 into the database because another trap comes
        in, saying the line goes down.

If I understand you correctly, you want to discard T+1 to T+4999.
This would mean I know nothing about the line state during T+1
to T+4999.  This simply isn't true.  I do know the line was active
hence I need to have that rate "1" in the database.

To put it the other way around: if I only poll the lines at infrequent
intervals, I cannot tell anything about T+1 to T+4999.  Therefore I
need to make this clear to RRDtool and I will have to do this:
T+0     update 0
T+4999  update U
t+5000  update 1

Now I have T+1 to T+4999 as NaN and *only* T+5000 as 1.  I think
this is what you're asking for? Note that if you try to fetch a
value from a device and fail to do so, you can store an unknown
in the database to signal this.

There is a BIG difference between not updating the database and
updating it with the unknown value.  In the first case, you rely
on the heartbeat value *and* the inserted value may be discarded.
In the second case, you are starting another interval.

> makes the most sense.  If the values in the RRDtool DB are the
> only thing surviving in a time history, and the presence or 
> absence of a value at a particular point in time is itself regarded
> as a datum, then inserting values into the RRDtool DB that never
> occurred (as in my case, with a heartbeat long in comparison to 
> the data gap) gives a false picture.  Similarly, once again for
> a GAUGE type only, throwing away the first datum that comes in
> after a gap (occurs for a heartbeat short in comparison to the
> gap) throwing away the first value that comes in presents
> a false picture.

You still seem to think you set the rate (or: a value) for time "T".
That isn't true.  You're entering a number that is valid for an entire
time range.

> I hope that you will consider this seriously and determine if
> what I'm suggesting as a fix, for GAUGE types, makes sense. 

>From what I understand, it doesn't make sense to me.  One of us
doesn't understand what's going on.  Either you've spotted something
and failed to describe it to me in a way I can understand, or you
don't understand something I've tried to explain.

cheers,
-- 
   __________________________________________________________________
 / 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 |
+----------------------------------------------------------------------+
| Technical questions sent directly to me will be nuked. Use the list. | 
+----------------------------------------------------------------------+
| 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