[rrd-users] rrd fetch changes between 1.0 and 1.2

[Gergely Madarasz]

On Fri, Feb 02, 2007 at 03:14:46PM +0100, Alex van den Bogaerdt wrote:
> Unfortunately a new bug has surfaced.  This was discussed a couple of
> days ago (21 and 22 January)
> Topic: "How are --start and --end supposed to behave?"
> 
> 1170422400:  1170422100 to 1170422400      Wrong, with 1.0
> 1170422700:  1170422400 to 1170422700       Good \
> 1170423000:  1170423700 to 1170423000       Good  > 1170422400..1170423300
> 1170423300:  1170423000 to 1170423300       Good /
> 1170423600:  1170423300 to 1170423600      Wrong, with current 1.2
> 
> > So 1.0 actually gives data corresponding to the interval asked in the
> > command line, while 1.2 gives an off-by-one result.
> 
> I hope you now understand that this is not true.

Thanks, it's clear now. Btw this bug breaks munin's definition of 'total'.

Munin adds together different defs, converting unknowns to zeroes, like this:
CDEF:gpostotal=gdev8_0_write,UN,0,gdev8_0_write,IF,gdev8_1_write,UN,0,gdev8_1_write,IF,+
not to have undef totals because of missing data.
Additionally munin sets the --end time to be on the exact boundary, but
still gets an additional data row coming from future, which is undefined,
gets converted to 0 in the total CDEF, so gpostotal:LAST becomes 0.

This also breaks the current values of all virtual graphs defined in
munin.conf by .sum. 

I guess the correct solution for rrd_fetch would be that no data is
supplied from the next interval if the endtime specified is exactly on the
boundary of the previous interval. 


-- 
Madarasz Gergely        gorgo at broadband.hu         gorgo at linux.rulez.org
    It's practically impossible to look at a penguin and feel angry.
        Egy pingvinre gyakorlatilag lehetetlen haragosan nezni.