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

[Y. Brett Sauer]

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)

sub update_rrdb {
        my ($host, $bitsin, $bitsout) = @_;
        `${main::rrd_exec_path}/rrdtool update ${main::rrd_data_path}/${host}.rrd
N:$bitsin:$bitsout`;
        ...
}

RRDtool would appear to have no way of knowing what I'm feeding it, so I am going
to run into a problem.  (I verified this with some tests that made the counter
appear to roll over.)

Is there a way (besides storing bytes) to do what I am trying to do?

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

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