Code

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)
commit08e5047f61f96e932278dddb6d5248807303dbf0
treebfa731c0e2b9783c0564b813728f5ce8b0d32f38
parent5c9778cdde4c44a9cd71fb975a2a6c0cd87e6fbc
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@2024 a5681a0c-68f1-0310-ab6d-d61299d08faa
program/src/rrd_update.c