[rrd-developers] Re: Restarting devices

[Y. Brett Sauer]

Alex van den Bogaerdt wrote:

> Y. Brett Sauer wrote:
> >
> > disappointed at the appearance of the 132917.92 and 128092.54 values for
> > average utilization in octets/second.  The previous calculated value for
> > utilization was, presumably, changed to a NaN in the archive, because it
> > exceeded the maximum allowable value, but the corresponding counter
> > value (or is it the utilization value?) appears to have been taken into
> > account in the next calculation.  Am I correct about this discrepancy?
> >
>
> I think both problems can be explained:
>
> After deleting and editing etcetera, I think this is wat you are
> feeding into rrdtool:
>
>    rrdtool update cust2.rrd 949001407:2848207042:2744819185
>    rrdtool update cust2.rrd 949001506:U:U \
>                             949001507:0:0
>                             949002007:2848207648:2744819601
>    rrdtool update cust2.rrd 949002308:2848208129:2744819897
>
> Presumably you find out at time 949002007 that a reset has occured.
> You then subtract the sysUptime from 949002007 to get 949001507 at
> which time the reset should have happened.  So far so good.
> As you notice, you need to feed the [u]nknown values one second before.
> This is still as expected.  Next isn't.  The whole idea was to detect
> a drop in the counter values.  This can be detected by monitoring the
> sysUptime value (or:  this was the general idea).
> Either your values are test values and you forgot to reset the counters,
> or your device does not reset the counters when resetting the system ...
>

The data are only fabricated values, unrealistically modified from previous
SNMP query results and stored in a file.  The fact that the counter value
does not look as though it has been reset was, initially, an accident, but
I became curious and a little concerned about how exactly (and why) it came
up with the (or any) average value for the next interval.

>
> As for this huge value:
>
> - at time 949001506 the counters are unknown
> - at time 949001507 the counters are known to be zero
> - at time 949002007 the counters are known to be *very* large again
>
> In 500 seconds, the counters increase by 2848208129 and by 2744819897.

Do you mean 2848207648 and 2744819601, which are the counter values for the
update that occurred at time 949002007?  (It doesn't make much difference to
the arithmetic, either way, but I want to make sure I understand what is
happening.)

>
> This is 5696416 and 5489639 per second.  Part of these absurd average
> values are in the 949002000 to 949002300 interval.
>
> They are:
> 5696416/300 *7 = 132916
> and
> 5489639/300 *7 = 128086
>
> The remaining few bits come from the next update.

Thank you very much for taking the time to wade through all my data and
results and to explain the details; I believe I now understand better how
things work.

The question I initially meant to ask is still dangling:
The average values 5696416 and 5489639 obtained for the 500-second interval
just following the presumed counter reset (or even their adjusted 300-second
interval values, I believe) exceed the maximum value (256000) I specified for
the DS;  why does RRDtool go through with the calculations for the next
interval, using these 'bad' values?  Shouldn't it come up with NaN for the
949002300 interval?

                 octetsin     octetsout
 948999900: nan0x7fffffff nan0x7fffffff
 949000200: nan0x7fffffff nan0x7fffffff
 949000500:         39.36        216.65
 949000800:          1.05          5.78
 949001100:         47.14         37.10
 949001400:          2.68          1.78
 949001700: nan0x7fffffff nan0x7fffffff
 949002000: nan0x7fffffff nan0x7fffffff
 949002300:     132917.92     128092.54
 949002600:          0.04          0.03

>
>
> I'm curious for the reason why your counters do not reset ?
>

Understandable!

Thanks again.

Brett

>
> Regards,
> --
>    __________________________________________________________________
>  / 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 |
> +----------------------------------------------------------------------+

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