author | oetiker <oetiker@a5681a0c-68f1-0310-ab6d-d61299d08faa> | |
Tue, 2 Mar 2010 23:22:35 +0000 (23:22 +0000) | ||
committer | oetiker <oetiker@a5681a0c-68f1-0310-ab6d-d61299d08faa> | |
Tue, 2 Mar 2010 23:22:35 +0000 (23:22 +0000) | ||
commit | 08e5047f61f96e932278dddb6d5248807303dbf0 | |
tree | bfa731c0e2b9783c0564b813728f5ce8b0d32f38 | tree | snapshot |
parent | 5c9778cdde4c44a9cd71fb975a2a6c0cd87e6fbc | commit | diff |
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
... 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 | diff | blob | history |