[rrd-users] Re: [rrd-developers] RRDtool algorithms and IEEEmath compilerquestion

[Y. Brett Sauer]

Tobias Oetiker wrote:

> Yesterday you sent me mail regarding [rrd-users] Re: [rrd-developers]...:
>
> *> Tobi,
> *>
> *> Thank you for all your responses; they were very helpful.
> *>
> *> A couple of follow-ups...
> *>
> *> RE:  3b  -  The counter on the device stores bytes, with a max value of 2^32-1, but
> *> I'm passing bits to the database:
> *>
> *> update_rrdb($main::customers{$_}, $octetsin*8, $octetsout*8)
>
> don't do that ...
>

I think I got the idea from an example on the old RRDtool tutorial web page.

>
> *> Is there a way (besides storing bytes) to do what I am trying to do?
>
> yes, store octets and use the CDEF funtion in the rrdgraph to fix the
> presentational things ...
>

Thanks again for the responses.

However, I'm not using the graphing functionality of RRDtool; just the database and
archiving.  Another script runs nightly that grabs 24 hours worth of data from the
RRDtool databases and inputs it into a centrally accessible Informix database.  Then,
once a month, that data will be queried and processed by a billing algorithm.  The
requirement is that utilization be stored in that database as bits per second.

I guess I'll just need to feed RRDtool bytes in and bytes out and translate the averages
from bytes per second into bits per second when I transfer the data to the other
database.  Not a big deal to implement, obviously; it just seems like it would be common
for users to want to see bits per second even when doing a fetch.  ?

Also, I believe this means I will have to change the maximum allowable calculated value
for the DS from 2.048(1024^2) (the speed of an E1 line in mbps) to the equivalent value
in bytes per second, which is also not a big deal but seems a bit kludgy.  ?

BTW - I just saw that Alex van den Bogaerdt's RRDtool tutorial web page has been updated
and has a new section called "RRD under the Microscope" that describes how RRDtool
handles counter-wrapping and data interpolation.  This is great.  I wish I'd noticed it
before I pestered you with some of my questions.

Thanks.

Brett

--
Brett Sauer                     Network Management Engineer
cell/pgr:(612)889-6397          Central Operations
phone:(512)252-8590             WAM!NET Inc.
vmail:(651)256-5467             14437 Robert I. Walker Blvd
brett at wamnet.com                Austin, TX 78728




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