Hi, On Tue, Jul 28, 2009 at 11:14:21PM +0200, Grzegorz Janoszka wrote: > Have you had similar problems? It is not the big issue, only the graphs > look not so nice with the rows of spikes down/up. If there is a simple > solution to the problem we would like to know it.
Well, I think this is just the way this architecture works. The hardware
does the actual counting, and every now and then a low-prio process grabs
all the counters from the hardware and fills in SNMP variables.
We haven't seen delays up to 3-4 minutes, just the normal 30-60 second
stuff - so our graphing (based on 5-minute samples) isn't really affected
by it.
When we do "real-time" monitoring ("there is a big customer event today,
we need to see quickly whether some pipes are filling up") we do rolling
averages, similar to what the "5 minute input" counters in IOS do - don't
use the SNMP counters "as is", but average with the last few values, to
smooth out the curves (and we don't use "nothing has changed" values as
"0 Mbit", but we wait for a change, and then calculate the bandwith based
on the number of seconds since the last change). We still get jumps, but
much more sane values overall.
So indeed, there is something that can be done on the display side - and
nothing I know of that can be done on the rotuer side.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany [email protected]
fax: +49-89-35655025 [email protected]
pgp1fWmbKi7VJ.pgp
Description: PGP signature
_______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
