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
_______________________________________________ rrd-users mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users
