Hi Thorsten, droping end time matching seems like a very simple and good solution to this problem ... will do ... thanks for the idea ...
cheers tobi Yesterday Thorsten von Eicken wrote: > I'm having trouble when generating graphs that end after the last update > time of an RRD. The problem is that I sometimes get a much coarser RRA > than I should. The issue is that in rrd_fetch_fn there is code to > determine the best partial match which kicks in when plotting past the > end of the RRAs and if the step times of the RRAs aren't multiples of > one-another strange things happen. > > The code calculates the matched time portion as follows (approx line 276 > of rrd_fetch.c): > /* best partial match */ > tmp_match = full_match; > if (cal_start > *start) > tmp_match -= (cal_start - *start); > if (cal_end < *end) > tmp_match -= (*end - cal_end); > I don't understand the purpose of calculating the end-time coverage. As > far as I know, all RRAs end at the same time, modulo their respective > step sizes. So they all cover up to the last update moment (again, > modulo step size) and we should really exclusively focus on the start > time coverage. > > Here is the abnormal situation I run into. I have RRAs with step sizes > (in seconds): 20, 140, 1020, 4520, 13440, 53360. Suppose I need to plot > a graph ending at 1203888560 when the last update time was 1203888537. > The last points stored in the first 4 RRAs are: > 20: 1203888537 - 1203888537 % 20 = 1203888520 > 140: 1203888537 - 1203888537 % 140 = 1203888420 > 1020: 1203888537 - 1203888537 % 1020 = 1203887640 > 4520: 1203888537 - 1203888537 % 4520 = 1203888440 > Now suppose the requested start time can be covered by the second (140 > second) RRA, you'd expect that to be chosen, but because the last point > of the RRA @4520s step happens to be 20 seconds later you get that one > instead! > > The net result is that depending on how the end times of the various > RRAs line up you get a plot for the last day (that's what the 140 second > step RRA is used in my case) that uses the 4520 second step RRA which is > designed for the one month view! Not nice at all. > > I suggest removing the partial-match adjustment based on the end time, > but maybe I'm missing a use-case where this is important. > Regards, > Thorsten > > _______________________________________________ > rrd-developers mailing list > [email protected] > https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers > > -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten http://it.oetiker.ch [EMAIL PROTECTED] ++41 62 213 9902 _______________________________________________ rrd-developers mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers
