[rrd-developers] RRD data structure "flaw"?

[steve rader]

I did #define DEBUG in rrd_update.c from v1.0.7 and exercised
the code until I got a (albeit vague) understanding of "rrdtol
update".  I'm pretty sure there's an inherient flaw in RRD data
structures: a notion of last_update needs to be kept for each DS.

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!

The example: when my scripts update the DS input at 937870600 the
last update for the DS output is assumed to be 937870600 and thus
a update for the DS output at 937870601 doesn't "work right".
I did:

  ./rrdtool update MadisonSD.rrd 937870000:1340000000:1340000000
  ./rrdtool update MadisonSD.rrd 937870300:1340010000:1340010000

so the RRD has lastupdate = 937860300

Next I did:

  ./rrdtool update MadisonSD.rrd -t input 937870600:1340020000

and so lastupdate = 937870600 and debug sez occu_pdp_st = 937870500.

Lastly, I did

  ./rrdtool update MadisonSD.rrd -t output 937870601:1340020000

and rrd_update.c finds proc_pdp_st = 937870500 and occu_pdp_st
937870500.  (I think this is only half right!  I think the occu_pdp_st
for the DS output should be something like 937870200.)

Thus rrd_update.c (on line 348) thinks that a PDP step has not
occurred and thus does not, ah, "process" the new PDP into *any*
RRA.  =:(

So, IMHO, it seems inherently obvious that RRDs must have a per-DS
notion of last_update for asynchronous DS updates to really work right.

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