I think I just solved a longstanding bug in the rrd_update routine
authoroetiker <oetiker@a5681a0c-68f1-0310-ab6d-d61299d08faa>
Tue, 2 Mar 2010 23:22:35 +0000 (23:22 +0000)
committeroetiker <oetiker@a5681a0c-68f1-0310-ab6d-d61299d08faa>
Tue, 2 Mar 2010 23:22:35 +0000 (23:22 +0000)
commit2c2a2654452de47d1504e7a5b6e4e63d0abb860e
treee1a2d65e62e156c289111a4b13f0c079fce73221
parentc58468053158550642d5cc92400a09cfb7b75376
I think I just solved a longstanding bug in the rrd_update routine
... I am writing a tool for seeding new rrd files from an existing
one ... essentially enabeling arbitrary restructuring ...

while doing this I found the following:

pdp:     1 2 | 3 4 5 6 7 | 8 9

for a consolidation of 5 steps I get

AVG RRA  ..  |         5 | ..
MIN RRA  ..  |         2 | ..
MAX RRA  ..  |         7 | ..

while I would have expected to get

AVG RRA  ..  |         5 | ..
MIN RRA  ..  |         3 | ..
MAX RRA  ..  |         7 | ..

the behavior has been like this at least since 1.2

looking at the code I found that the behavior had been introduced
by a patch optimizing rrd_update for updates covering multiple pdps
in one go ... in that optimization, the normal case where an update
covers exactly ONE pdp had been sort of neglected ... so much for
tunel vision.

The problem was, that the cdp value for MIN and MAX got initialized
from the last pdp value BEFORE the consolidation interval ... for
normal data no one would notice (or did notice) but it is still
wrong ...

git-svn-id: svn://svn.oetiker.ch/rrdtool/trunk/program@2024 a5681a0c-68f1-0310-ab6d-d61299d08faa
src/rrd_update.c