[rrd-users] VDEF min/last incorrectly show NaN

[Ryan Kubica]

I'm trying to resolve an issue with rrd graphing which has the min/last values 
showing NaN (in my example case below they show zero since I convert NaN to 0.)

What's the trick to getting a graph to always have data available in the last 
pixel of the graph so min/last will have data for the legend?

I have a graph generator that accepts an end_time; this end_time is already in 
the past, new records since exist, so it's not an issue of the last_update being 
the last  record I'm choosing.

It seems to be correlated to graph width and time frame (start <-> end).  

As an example: step 60, two different widths, 287 pixels and 288 pixels for a 2 
day period (2880 1 minute datapoints.)

http://stalemate.vendetta.com:7171/waterware?a=g&ds=loadavg1&n=tuolumne&e=1300491600&w=287
 (correct)
http://stalemate.vendetta.com:7171/waterware?a=g&ds=loadavg1&n=tuolumne&e=1300491600&w=288
 (shows  zero)

The interesting part is that the zero's show until 575 pixels - which is 
coincidentally close to 287*2+1.

So why?

It doesn't always  happen either, if I subtract 40 seconds off the end_time used 
then  data shows at 288 pixels.

http://stalemate.vendetta.com:7171/waterware?a=g&ds=loadavg1&n=tuolumne&e=1300491560&w=288


However, subtracting 40 seconds from the next interval doesn't work.

On this host I'm using rrdtool version 1.4.2 - however this happens with 1.4.5 
as well.

I found this old ticket, but the resolution in it is not 
satisfactory: http://oss.oetiker.ch/rrdtool-trac/ticket/155

I currently do _not_ convert min/max to 0 from NaN in the hopes that most of the 
time it will show properly; but when some data is NaN in more complex RPN 
calculations it's better to have it 0 than a failure ... ie: NaN shows up anyway 
at min/max under that situation because I'm not converting.

I'm trying to fix that behavior (hence the test case above); I'm trying to use 0 
in all calculations with no luck - and it's obvious that it's due to pixels and 
time-width - just not sure why.

This issue exists for every datapoint I checked stored at that time interval, 
not just loadavg1.  So it definitely seems to be a fundamental issue with 
fetching and graphing that time for that pixel width.

Lastly, I've tried:

   1) having rrdtool fetch a little extra data PAST the end of the graph (on the 
DEF:) but that doesn't work either.
   2) time/pixel division to set graph width to match for whole integer/even/odd 
datapoints per pixel - nothing works

 
Thanks,


-Ryan

------ fetch data ------

1300491420: 2.4000000000e+01
1300491480: 4.6000000000e+01
1300491540: 4.1000000000e+01
1300491600: 4.6000000000e+01
1300491660: 4.2000000000e+01
1300491720: 3.2000000000e+01
1300491780: 4.3000000000e+01
1300491840: 4.7000000000e+01


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.oetiker.ch/pipermail/rrd-users/attachments/20110319/19ae9ff4/attachment-0001.htm