# [rrd-developers] Re: Implementing TOTAL

Alex van den Bogaerdt alex at slot.hollandcasino.nl
Fri Jul 27 00:26:24 MEST 2001

```Mark Mills wrote:

> > > Do both? TOTALSUM, TOTALAVG are really ugly suggestions for
> > names. =)
> >
> > They're not clear to me and this is within context :)
>
> Ouch. I did say they were ugly names. ;) In any case, TOTAL
> should be "TOTAL" and leave unknown treated as zero.

This is clear.  Rate from defined intervals, times stepsize.
You prefer NOT to include an assumed rate for the unknown
intervals.

> If you
> want to make up data it isn't a TOTAL but an adjusted total
> and your next problem will be what KIND of adjustments to
> make. Some people might want an interpreted adjustment rather
> than presuming a raw average for the unknowns.

And this will be *very* hard.  Or at least I think so.
Unknown can occur due to several things.  We cannot assume it became
unknown because it was below the minimum rate, or above the maximum
rate, or because of a SNMP-engine reset.  The only *reasonable* thing
to assume (and this is, indeed, no more than an assumption) is that
it will be close to the average, *on average*.  Whatever we do, we
need to assume something for unknowns.  The "real" total assumes
rates were zero if unknown.

And yes, I'm still struggling for the "correct" way to handle this.

People, please join the discussion and tell us what you think is
best to do.

> Would thse work for TOTAL and ADJUSTED? (No dev box yet *sniff*)
>
> 	case VDEF_TOTAL: {
> 	    double sum=DNAN;
> 	    for (step=0;step<steps;step++) {
> 		if (finite(data[step*src->ds_cnt]) &&

> !isnan(data[step*src->ds_cnt]))

I removed this check as it is redundant.

> 		    sum += data[step*src->ds_cnt];
> 	    }
> 	    if (!isnan(sum)) {
> 		dst->vf.val  = sum*src->step;

> 		dst->vf.when = 0;	/* no time component */

I changed this to present the number of defined seconds.  Currently
this is not usable but it will be.

> 	    } else {
> 		dst->vf.val  = DNAN;
> 		dst->vf.when = 0;
> 	    }
> 	    }

This would calculate: sum(rate).  This is not the total.  Each interval
contains a rate, this should be "x per second".  Unless you multiply
by "seconds" you'll never end up with "x".

Even in the case where you don't really store a rate, RRDtool will
still "assume" it is a rate. This is important for the consolidation
functions.

[snip]

> Hey, since I'm cut-n-pasting your code around, why does AVERAGE
> have step++ in it twice??? I took it outta mine because it looked
> like a holdover from the while(){} loop style you had in much of
> the other VDEF_ cases.

It *used to be* a bug.  It is already fixed.  Hey, you did read the
warning about it being alpha code, didn't you :)

Anyway, if you're using the cvs then it's time to "cvs update".  If
you've found the super-duper-secret (as it is not announced) extract
on the website you need to download the entire tree frequently.

cheers,
--
__________________________________________________________________
/ alex at slot.hollandcasino.nl                  alex at ergens.op.het.net \
| work                                                         private |
| My employer is capable of speaking therefore I speak only for myself |
+----------------------------------------------------------------------+
| Technical questions sent directly to me will be nuked. Use the list. |
+----------------------------------------------------------------------+
| http://faq.mrtg.org/                                                 |
| http://rrdtool.eu.org  --> tutorial                                  |
+----------------------------------------------------------------------+

--
Unsubscribe mailto:rrd-developers-request at list.ee.ethz.ch?subject=unsubscribe
Help        mailto:rrd-developers-request at list.ee.ethz.ch?subject=help
Archive     http://www.ee.ethz.ch/~slist/rrd-developers
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi

```

More information about the rrd-developers mailing list