Okay, I found the bug. The problem is that partial matches were resetting the 'best_step_diff' value. Using debug showed this: bash-3.00# ./rrdtool fetch /d/rrd/stats/bd/metro2.5.7.rrd AVERAGE -e 22:00 -s end-168h -r 1800 2>&1 | head -10 Entered rrd_fetch_fn() searching for the best match Looking for: start 1140069600 end 1140674400 step 1800 Considering: start 1137221100 end 1140677100 step 60 best full match so far Considering: start 1139236200 end 1140676200 step 1800 best full match so far Considering: start 1134914400 end 1140674400 step 7200 full match, not best Considering: start 1071532800 end 1140652800 step 86400 best partial so far Considering: start 1133765100 end 1140677100 step 300 best full match so far We found: start 1140069600 end 1140674400 step 300 rows 2017
What was happening was that the partial match of 86400 reset the best_step_diff, and then the 300 full match was a closer differential. Careful ordering of the RRAs in the RRD file would not see this problem. However, the patch was simple -- have best_full_step_diff and best_part_step_diff. A patch is attached, and it works perfectly with everything I can see. -- Attached file removed by Ecartis and put at URL below -- -- Type: application/octet-stream -- Size: 1k (1492 bytes) -- URL : http://lists.ee.ethz.ch/p/02-patch-rrd_fetch.c -- Binary/unsupported file stripped by Ecartis -- -- Err : No filename to use for decode, file stripped. -- Type: text/plain -- Unsubscribe mailto:[EMAIL PROTECTED] Help mailto:[EMAIL PROTECTED] Archive http://lists.ee.ethz.ch/rrd-developers WebAdmin http://lists.ee.ethz.ch/lsg2.cgi
