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

[Alex van den Bogaerdt]

All my stuff below is strictly AFAIK and IMHO, comments welcome.

The real guru is having his well-earned holidays, perhaps some
of the other gurus (for values of guru that approach author) can
comment on the understanding of the rrdtool internals of us both.

> 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!
> 

I think this is not the case. An update will do fine.

You have to look at the way values are stored in the RRAs:
- Data is collected whenever there is an update. If one of the 
  counters is not available it is unknown --> U.
- Whenever there is enough data to create a PDP it will do so. If
  your RRD is setup to get PDPs at every 300 seconds it will do so
  when ( (time() % 300) == 0 ).
- When there are enough PDPs to fill a slot in the RRA, this will
  happen.

When you update the database at times 937870000, 937870300 and
937870600, you will have the following behaviour:

time 937870000: the slots upto 937869900 get filled, you have a
                portion of slot 937869900..937870200
time 937870300: the slot at time 937870200 gets filled, 
time 937870600: the slot at time 937870500 gets filled.

An update at 937870601 will now correctly be calculated from time
937870500 to 937870601.

> 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.)
> 
Nope, see above.

> 
> 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.
> 
Nope, but if you still have problems and are getting unknowns in your
RRA (which has one PDP per row) there may be another problem.
This of course if the missing time (937870500-937870300==200) is okay
as far as rrdtool is concerned (xff setting). In this case I think
it is not okay to have 0.5 . 

For related data (such as counterIn,counterOut) it is okay to assume
simultanious updates. For unrelated data you could create multiple
RRDs and have those per-DS stats this way.

Regards,
Alex

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