[rrd-developers] problems graphing past end of RRD

Thorsten von Eicken tve at voneicken.com
Mon Feb 25 01:52:31 CET 2008

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

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.

More information about the rrd-developers mailing list