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:[EMAIL PROTECTED] Help mailto:[EMAIL PROTECTED] Archive http://www.ee.ethz.ch/~slist/rrd-users WebAdmin http://www.ee.ethz.ch/~slist/lsg2.cgi
