Hi Tobi and all, I found the piece of code that does wrong, but I need your help in fixing that.
--- Stanislav Sinyagin <[EMAIL PROTECTED]> wrote: > Sometimes LINE2 is drawn with a bigger step than it's > defined in RRD, though the rrd_graph arguments are > the same. > > See these examples: > > Correct graph (except that TICK doesn't work): > http://ipv6.multikabel.net/render-correct-1.bmp > > Weird graph: > http://ipv6.multikabel.net/render-fault-1.bmp Thus, the RRD is created with the following RRAs, in the following sequence: RRA:AVERAGE:0:1:4032 RRA:AVERAGE:0:6:2016 RRA:MAX:0:6:2016 RRA:AVERAGE:0:288:732 RRA:MAX:0:288:732 Then, with DEBUG enabled in src/rrd_fetch.c, after few thousand of looped rrdtool graph runs, I got the following debug output: Entered rrd_fetch_fn() searching for the best match Looking for: start 1042459233 end 1042545633 step 172 rows 502 Considering: start 979257600 end 1042502400 step 86400 best partial so far Considering: start 1038916800 end 1042545600 step 1800 best partial so far Considering: start 1041336000 end 1042545600 step 300 partial match, not best We found: start 1042459200 end 1042547400 step 1800 rows 49 This means that in the loop at line 208 of src/rrd_fetch.c, the condition "if (first_part || best_match < tmp_match)" at line 250 was false for the row with step 300. I think that changing the condition to "if (first_part || best_match <= tmp_match)" would help in my case. But that works only if the RRAs are sorted by the step size. This is where I stuck: are the entries in this loop sorted or not? With regards, Stan. -- Unsubscribe mailto:[EMAIL PROTECTED] Help mailto:[EMAIL PROTECTED] Archive http://www.ee.ethz.ch/~slist/rrd-developers WebAdmin http://www.ee.ethz.ch/~slist/lsg2.cgi
