[mrtg] Re: Wan spikes

[Kerry Kincaid.]

I do not have unknaszero as an option for this device.  I considered that
first.  My understanding of MRTG is that if it can not get a valid number
from a device, then it assumes the last accurate value for the current
value, to prevent this very thing, then the spike isn't near as large as it
would be assuming zero.  My link is currently down and I am showing a
current value of 0.00.  I'm sure I'll get another large spike if I can ever
get Verizon to fix my connection. 

The only other option I can think of is to lower the MaxBytes value to a
value that is closer to the highest actual value I've ever received from
this device, say 100k instead of the actual possible speed of the Ethernet
interface that is 10Mbps.  However, wouldn't this change my percentages for
line usage?

The only other thing I can think of is to have an MRTG server at that
location so it never has to be worried about the WAN link.  Not a cost
effective solution though.

Kerry

-----Original Message-----
From: Paul C. Williamson [mailto:pwilliamson at mandtbank.com]
Sent: Friday, August 31, 2001 9:11 AM
To: mrtg at list.ee.ethz.ch; bruno.weymiens at rd.francetelecom.com;
david.sawyer at uk.mckhboc.com
Subject: RD: [mrtg] Re: Wan spikes



Sounds like that is in the config now. If not, it probably would not help
matters.

Paul

>>> David Sawyer <david.sawyer at uk.mckhboc.com> 08/31/01 08:38 AM >>>
I suppose not having 'unknaszero' would lessen the spikes?

> -----Original Message-----
> From:	Paul C. Williamson [SMTP:pwilliamson at mandtbank.com]
> Sent:	Friday, August 31, 2001 1:31 PM
> To:	mrtg at list.ee.ethz.ch; bruno.weymiens at rd.francetelecom.com
> Subject:	[mrtg] Re: Wan spikes
> 
> 
> The easiest explaination is this:  MRTG does rates.  
> 
> MRTG retrieves a value.  No response.  MRTG, thinks, "Great, 
> I'll just enter a zero."  Next time, gets the same thing, no response, 
> zeo goes into the log.  Then the next time, it gets a response, and it 
> is huge.  So the rate for that period of time is huge.  The problem is
> thec
>  ounter was incrementing the whole time mrtg could not talk to the device,
> but the device did not know that.  Then the next poll, it gets a
> huge+smallv
>  alue, and puts that in as the rate between n and n-300 seconds.  It
> happens 
> sometimes when you first start monitoring devices as well.  
> It's a problem, but I don't know how I'd solve it with MRTG.  Sounds likeo
>  nce you are able to poll the device, you need to reset the counters
> BEFOREm
>  rtg can poll it again.  That will eliminate the possibility of the huge
> spike.
> I know that isn't realistic all the time, but it may get someone
> thinking...
> 
> Paul
> 
> 
----------------------------------------------------------------------------
The information contained in this e-mail is confidential and is intended
only for the named recipient(s). If you are not he intended recipient you
must not copy, distribute, or take any action or reliance on it.
If you have received this e-mail in error, please notify the sender.
Any unauthorised disclosure of the information contained in this e-mail
is strictly prohibited.
----------------------------------------------------------------------------




--
Unsubscribe mailto:mrtg-request at list.ee.ethz.ch?subject=unsubscribe
Archive     http://www.ee.ethz.ch/~slist/mrtg
FAQ         http://faq.mrtg.org    Homepage     http://www.mrtg.org
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi



--
Unsubscribe mailto:mrtg-request at list.ee.ethz.ch?subject=unsubscribe
Archive     http://www.ee.ethz.ch/~slist/mrtg
FAQ         http://faq.mrtg.org    Homepage     http://www.mrtg.org
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi