[rrd-users] Re: Problem on update

[Chris Raymond]

Replying to messages from both Tobi Oetiker and Alex van den Bogaerdt:

Tobi Oetiker wrote:

>set the minimal required heart beat to 4000 or some such and then
>you will see a result as you expect it ...

Yes, I have done so.  However, there's a theoretical question here:
whenever the first point comes in after the heartbeat, in the current
design, it's discarded.  That, to me, does not seem to apply in all 
cases when we're talking about something that's represented by a 
GAUGE DS-type.  The code patch I included in my original post, combined
with a long heartbeat, produces a data set which I think is more
in tune with reality.  See my reply to Alex, below.

Alex van den Bogaerdt wrote:

>I think this is an expectation problem.
>
>You expect to insert a data POINT.  This is not what RRDtool does.
>RRDtool inserts, with one update, a range.  This is from the last
>update to the current update.
>
>Let's see if you and I agree on the situation.  The numbers don't
>necessarily match your examples:
>
>step time:  3600
>heartbeat: 36000
>
>Updates:
>
>   T+1*3600:   value 1
>   T+2*3600:   value 2
>   T+3*3600:   value 3
><long time>
>   T+8*3600:   value 4
>
>You expect the following to be inserted into RRDtool:
>
>   at T+1*3600:  1
>   at T+2*3600:  2
>   at T+3*3600:  3
>   at T+8*3600:  4
>
<snip>
>   at T+1*3600:  the time range between T+0*3600 and T+1*3600
>   at T+2*3600:  the time range between T+1*3600 and T+2*3600
>   at T+3*3600:  the time range between T+2*3600 and T+3*3600
>   no updates    the time range between T+3*3600 and T+7*3600 --> NaN
>   at T+8*3600:  the time range between T+7*3600 and T+8*3600
>
>For "time range" you could read "point" in your understanding.
<snip>
>  at T+1*3600:  the time range between T+0*3600 and T+1*3600
>  at T+2*3600:  the time range between T+1*3600 and T+2*3600
>  at T+3*3600:  the time range between T+2*3600 and T+3*3600
>  at T+8*3600:  the time range between T+3*3600 and T+8*3600
>
>Why is this last line different?  At time T+8 I enter a number.
>RRDtool hasn't seen any update between T+3 and T+8.  Therefore
>it *must* assume the update is valid throughout the entire time
>range *unless* this is larger than heartbeat.  This is how the
>tool is designed.  Since heartbeat is more than (8-3)*3600, the
>update is valid *for the entire range*.

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

I hope that you will consider this seriously and determine if
what I'm suggesting as a fix, for GAUGE types, makes sense. 
I can certainly modify the structure of my code to only apply
in such cases;  but it would be foolish to expend the time
if you think my suggestion does too much violence to the
structure of RRDtool.  

Thanks,
Chris R.

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