[rrd-users] Re: Spikes

[Alex van den Bogaerdt]

Daniel Rinehart wrote:
> 	Looks like I'll need to talk to Cisco on Monday then, because I'm
> not issuing a clear at all. I've also since observed this odd wrapping
> behavior just watching the output of 'show interface' without SNMP
> involved. At least, the interface isn't saying I am (output of sh int atm
> 0/0/1):
> 
Your interface showes a really low value for bytes received 

>  Last clearing of "show interface" counters never
>  Queueing strategy: fifo
>  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
>  5 minute input rate 0 bits/sec, 0 packets/sec
>  5 minute output rate 0 bits/sec, 0 packets/sec
>     17581 packets input, 931793 bytes, 0 no buffer

At 100bps this would be about 30 periods of five minutes or 2.5 hours uptime.

Tobi wrote:

> we might think of some sensibility check here: if a wrap occurs the data
> calculated by the wrap around code may only differ from the last value
> logged by a certain percentage ... otherwhise it goes *unknown*

This is true but IMHO only as a workaround.  Somewhere, somehow, a reset
is happening.  The normal values are in the 100bps range so a range check
of 200bps would be okay here for now, until the problem is fixed.
It would be bad to do this in the rrdtool code IMHO, either you know
what happens or you don't "fix" it in the code.  Using the rrd parameters
these strange values can be filtered out already:  you can do this using
"rrdtool tune filename -a dsname:200".

> 
> <!-- 1999-12-04 06:45:00 EST --> <row><v> 1.0106976708e+02 </v></row>
> <!-- 1999-12-04 06:50:00 EST --> <row><v> 9.4598140716e+01 </v></row>
> <!-- 1999-12-04 06:55:00 EST --> <row><v> 1.0237584918e+02 </v></row>
> <!-- 1999-12-04 07:00:00 EST --> <row><v> 1.4162561428e+07 </v></row>
> <!-- 1999-12-04 07:05:00 EST --> <row><v> 1.4268386264e+05 </v></row>
> <!-- 1999-12-04 07:10:00 EST --> <row><v> 1.0373755191e+02 </v></row>
> <!-- 1999-12-04 07:15:00 EST --> <row><v> 1.0108732455e+02 </v></row>
> 
Values are:
        94.598140716
       102.37584918
14,162,561.428
   142,683.86264
       103.73755191
       101.08732455

Previous mail:
>>                'atm_out' => 3438905,
>>                'atm_out' => 3457190,
>>                'atm_out' => 1484,
>>                'atm_out' => 19875,
>>
>>      Another sample:
>>                'atm_out' => 3421998,
>>                'atm_out' => 3452632,
>>                'atm_out' => 26394,
>>                'atm_out' => 58936,

These numbers differ about 30k, except at one point. 30k per 300sec is
indeed about 100 per second.
If the timestamps would be present we would probably see that the low
value is received at a time just past a 300-second boundary (about 10%
or 30 seconds) as this would explain the 14162M + 142M values.

Seems that the counter wraps somewhere near 346000, indeed a strange number.

Perhaps this call to cisco will help...

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

--
* To unsubscribe from the rrd-users mailing list, send a message with the
  subject: unsubscribe to rrd-users-request at list.ee.ethz.ch