[rrd-developers] problems graphing past end of RRD

[Tobias Oetiker]

Hi Alex,
Hi Thorsten,

ich habe altered the behaviour the svn for both trunk and 1.2
branche ... I think it makes sense to ignore the end time since the
end time is by default equal it only diverges as torsten explained
when step withs do not match up ...

I doubt that anybody 'expects' this behaviour ... at least not
judging from what I read on the list ...

cheers
tobi

Today Alex van den Bogaerdt wrote:

> On Sun, Feb 24, 2008 at 04:52:31PM -0800, 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
>
> s/should/want/
>
> > 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.
>
> A partial match covers the largest possible time range, not the
> best possible resolution.
>
> > 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
>
> Note how 1203888560 is larger than 1203888537. You can expect that
> rrdtool will not be able to exactly match your request, so you should
> expect the partial best match to kick in.
>
> > 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!
>
> More data, better match to what you ask (not want).
>
> > 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.
>
> Then ask for an end time which is a whole multiple of 140, and not later
> than last update time. If your match can be exactly matched, it will.
> If there are multiple choices left, rrdtool will select the best resolution.
>
> > I suggest removing the partial-match adjustment based on the end time,
> > but maybe I'm missing a use-case where this is important.
>
> Maybe. Changing this could mean a change of expected behaviour for
> a lot of other people.
>
>

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten
http://it.oetiker.ch tobi at oetiker.ch ++41 62 213 9902