Philip Molter wrote: > : I've setup a very basic file for testing. Two fields, 5 second > : intervals, starting at time $time ($time is adjusted to be on a 5 > : second boundary). > : > : Field test1 is a GAUGE > : Field test2 is a COUNTER > : > : At these times, I put in these values: > : > : Time test1 test2 > : ---------------------------- > : $time + 5 5 8 > : $time + 10 3 18 > : $time + 15 4 38
This means: interval $time..$time+5 has 5 and ((8-unknown)/5)==NaN interval $time+ 5..$time+10 has 3 and ((18- 8)/5)==2 interval $time+10..$time+15 has 4 and ((38-18)/5)==4 > Ugh, I upgraded everything to 1.0.33 and now graphing is one off > in the other direction. > > For example, with the same setup, I get these results from RRD fetch: > > Time test1 test2 > --------------------------- > $time + 5 5 NaN > $time + 10 3 2 > $time + 15 4 4 So, this is as expected. > But when I do averages using graph for the exact same start and > end times ($time + 5 through $time + 15), I get averages of test1:3.5 > and test2:3. The large interval time+5..time+15 has only two "real" intervals in it. The first being time+5..time+10, the other is time+10..time+15. The values are: (3+4)/2 = 3.5, (2+4)/2 = 3 > If I increase the period by doing (-s $time + 5 - > 1), then I get the correct values back using rrdgraph. If you increase the period by moving the start back in time, you ask for another interval. The numbers in that case: (5+3+4)/3 = 4, (NaN+2+4)/2 = 3 > Again, that seems like a pretty big inconsistency. I would expect > my 'graphed' values to be using the same data that my fetch query > returns. Apparently, now, graphing is inclusive of the ending > time, but exclusive of the start time, while fetching is still > inclusive of both. Fetch does show you the startout value. This value however is describing the period of time that is not inside your query. This may be considered a bug or a feature, depending on how you look at it. rrdtool graph does now graph the correct interval and it calculates averages over this interval. There used to be a bug in it and as you noticed, the last value was not taken into account. Even worse, the first value (which you couldn't see) was taken into account. That means that you could get a minimum that wasn't visible, a maximum that was visible but not printed and an average that didn't make sense. This was not a big problem for "normal" applications like data flowing through a router but as you noticed it did produce strange results for other kind of monitoring. cheers, -- __________________________________________________________________ / [EMAIL PROTECTED] [EMAIL PROTECTED] \ | 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:[EMAIL PROTECTED] Help mailto:[EMAIL PROTECTED] Archive http://www.ee.ethz.ch/~slist/rrd-users WebAdmin http://www.ee.ethz.ch/~slist/lsg2.cgi
