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 [EMAIL PROTECTED]
