[rrd-developers] example of broken asynchronous-DS updates (was RRD data structure "flaw"?)

[steve rader]

 > > From: me 
 > > The meta-theory: when "rrdtool update" for DS "input" happens
 > > at X, last_update gets set to X.  Then "rrdtool update" for DS
 > > "output" at X+1 simply *can't* Do the Right Thing because it
 > > thinks the last update was a second ago!
  
 > From: Alex van den Bogaerdt
 > I think this is not the case. An update will do fine.
 > [...]

Okay.  Your explanation makes sense.  

But here's a real-world example of the problem:

 rrdtool create MadisonSD.rrd --start 937844100 --step 300 \
   DS:input:COUNTER:300:U:U DS:output:COUNTER:300:U:U \
   RRA:AVERAGE:0.5:1:10

 rrdtool update MadisonSD.rrd -t input:output 937844400:2036007229:1286147890
 rrdtool update MadisonSD.rrd -t input:output 937844700:2051557700:1290492794
 rrdtool update MadisonSD.rrd -t input 937845000:2069078489
 rrdtool update MadisonSD.rrd -t output 937845001:1294770454
 rrdtool update MadisonSD.rrd -t input:output 937845300:2088835344:1298501078
 rrdtool update MadisonSD.rrd -t input:output 937845600:2109019482:1302230202

The update of "output" at 937845001 and "input" at 937845300
seem to have been "lost":

 bash% rrdtool fetch MadisonSD.rrd AVERAGE -s 937844700 -e 937845600
                input    output

  937844700:  51834.90  14483.01
  937845000:  58402.63       NaN
  937845300:       NaN  12477.00
  937845600:  67280.46  12430.41

I think this example demonstrates that asynchronous-DS updates
don't work right.  Correct?

later
steve
- - -
systems guy
wiscnet.net

--
* To unsubscribe from the rrd-developers mailing list, send a message with the
  subject: unsubscribe to rrd-developers-request at list.ee.ethz.ch