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

Fri Jan 21 07:17:21 MET 2000

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

*> 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 ... 

*> RE:  4b  -  The system is an SGI O2 running Irix 6.4.  I'm still trying to find
*> someone who knows about the compiler.  (I'm not a systems person.)

make sure you get a gcc 

cheers
tobi
*> 
*> Thanks again.
*> 
*> Brett
*> --
*> 
*> Tobias Oetiker wrote:
*> 
*> > Today you sent me mail regarding [rrd-developers] RRDtool algorithms and...:
*> >
*> > *> I am using the following statement to set up the RRD database and
*> > *> archive:
*> > *>
*> > *> rrdtool create ${main::rrd_data_path}/${host}.rrd --step 300
*> > *> DS:bitsin:COUNTER:600:U:U DS:bitsout:COUNTER:600:U:U
*> > *> RRA:AVERAGE:0.5:1:2304
*> >
*> > you should define the range of data you expect ... do NOT put U into the DS
*> > arguments ...
*> >
*> > *> 1a)    Given that counter values have been successfully obtained via
*> > *> SNMP and fed to RRDtool's update function for several sampling periods,
*> > *> how does RRDtool calculate average bits per second for the current
*> > *> period?
*> > build the difference from the last recorded value and devide by the time
*> > passed ... rrdtool integrates the space below the curve optained by looking
*> > at the counters ...
*> >
*> > *> 1b)    Presuming previous raw data values (in this case, counter values)
*> > *> are used in the above calculations, are these somehow accessible to the
*> > *> user?
*> > no they do not get stored ...only the rates get stored ... rrdtool dump
*> > shows you waht is in the database ..
*> >
*> > *> 2)    If data is missing for several sampling periods (more than two, in
*> > *> this case), how does RRDtool calculate the next couple of averages
*> > *> (i.e., bits per second)?
*> >
*> > once it gets a new counter value it stores it and when the next one comes in
*> > it builds the difference ...
*> >
*> > *> 3a)    How does RRDtool determine that a counter has rolled over?
*> > the difference is negative and by adding 2^32-1 the value becomes one which
*> > is in the range defined when the database was set up (dont use U in the DS
*> > argument)
*> >
*> > *> 3b)    What does it use for a maximum counter value?  (and wouldn't this
*> > *> be application specific?)
*> > it tries 2^32-1 and 2^64-1 as these are the values to be expected from sane
*> > snmp counters at this point in time ...
*> >
*> > *> According to my information, the maximum value for the counter in this
*> > *> case is 2*32-1.  I did an RRDtool update using the value "0" for input,
*> > *> and when I did an RRDtool fetch for this period the value for average
*> > *> bits per second was an unduly high number, *much* greater than 2*32
*> > *> minus the previous counter value.
*> >
*> > for bug reports please suply some sample code demonstrating the 'bug'
*> > *>
*> > *> On a completely different note (or so I hope) ...
*> > *>
*> > *> 4a)    In order to get RRDtool to compile on our system, I commented out
*> > *> a line in the "configure" file containing the test "if (nan == nan)".
*> > *> Is this likely to cause any real problem(s)?
*> > yes, NaN is NOT NOT NOT equal to NaN this is a basic property of NaN ...
*> > check how to get the IEEE math right on your system ... Its not that rrdtool
*> > must fail if this is not given, but I would be carefull as this test works
*> > fine on most systems so there might be hidden issues with this when it does
*> > not work on your system ...
*> >
*> > *> 4b)    If so, what are some possible ways around this?
*> > make it work ... what sort of a 'system' is it ?
*> >
*> > cheers
*> > tobi
*> > *>
*> > *> Thanks very much.
*> > *>
*> > *> 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-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
*> > *>
*> >
*> > --
*> >  ______    __   _
*> > /_  __/_  / /  (_) Oetiker, Timelord & SysMgr @ EE-Dept ETH-Zurich
*> >  / // _ \/ _ \/ / TEL: +41(0)1-6325286  FAX:...1517  ICQ: 10419518
*> > /_/ \.__/_.__/_/ oetiker at ee.ethz.ch http://ee-staff.ethz.ch/~oetiker
*> 
*> --
*> 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
*> 

-- 
 ______    __   _
/_  __/_  / /  (_) Oetiker, Timelord & SysMgr @ EE-Dept ETH-Zurich
 / // _ \/ _ \/ / TEL: +41(0)1-6325286  FAX:...1517  ICQ: 10419518 
/_/ \.__/_.__/_/ oetiker at ee.ethz.ch http://ee-staff.ethz.ch/~oetiker

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