On Fri, Dec 29, 2000 at 11:36:28AM -0500, David Koski wrote: > > Dave, > > Just to clarify... I'm moving from COUNTER to DERVIE with rrd-min > set to 0 to remove any spikes that occur in the couter wrap code due to > huge counter wraps, router reloads, etc. Since RRD tries to compensate > for the counter roll instead of just throwing out the data (AKA Concord > Network Health's way of dealing with a counter roll), I need some way to > just ignore any spike that could occur in the RRD counter wrap logic.
Thanks for the clairification... I like that method of just discarding the value when the counter wraps. In RRD terms that would mean recording the PDP Status info, but storing NaN (Tobi's *UNKNOWN*) in the RRA, which sound like what will happen if you switch to DERIVE with the DS' min set to zero. > Since folks both here and on the cricket list seem to lean twards the only > "neat" way to get rid of such a spike occurance is to move to DERIVE with > an rrd-min of 0 to ignore any negative deltas on the graph (Without having > to worry about anyones buggy implementation of SNMP), seems about the best > way I can get around having to constantly explain weird spikes to > customers :) Agreed. Anyway, I think you'll have good luck modifying the RRD files using XML dump and restore as I mentioned in the previous follow-up. > Also to clarify my mixture of Gauge and Counter explanation. Currently > I'm using 32 bit traffic counters for anything under 12 megs (Cisco > routers), and anything over 12 megs I'm using Cisco ifloc integers. > Works for now, but since the ifloc integers are really unsupported and > Cisco claims they are going to eventually disappear (?), so we will > eventually move everything possible to a 64-bit ifHC counter, however I'm > having some strange problems with HUGE spikes occuring on every sub > interface (ATM, FrameRelay and channelized interfaces) all at the same > time (AKA Peta bits per second). Hmmm... I think we're getting mostly good values from our HC counters, but most of those are on ethernet switch ports rather than router interfaces, so its very different Cisco hardware and code than on your routers. I'll keep your report in mind when we consider using the HC counters on our WiscNet routers. > I've not been able to blame anything as > of yet. However, I'm not trying to compensate for the 64-bit problem at > this point only the once in a while occurance of a huge spike in a 32-bit > graph. The unfortunate part is I have about a years worth of data stored > in RRDs at this point and would like to maintain that data that would not > shift to a 64-bit counter (Non-backbone customer router, I.E. Cisco 2501 > running 11.x) I'm missing why that's unfortunate, unless you mean that you must figure out how to preserve your existing data. (Personally, I think it'd be more unfortunate if you discarded it!) If you wish, use Cricket's "events" to record the point in time at which you switched from COUNTER to DERIVE. That will help to explain why your MAX values before that even are sometimes unreasonably high, and also that the AVERAGE values may have been skewed by those bad samples. As an aside, if you haven't come across this already, perhaps you can avoid the mistake we made by assuming that the presence of the High Capacity interface counters on a Cisco meant that they actually worked. We use a customized Cricket "listInterfaces" script which uses SNMP v2c to test whether or not the ifHC counters were present and use them accordingly. Months later, what we found with some Cisco equipment (such as the 3500XL switches running IOS 12.0(5)XU) is that the HC counters are there, but always report zeroes. Our current kludge is to test the sysDescr - if it contins "C3500", we disregard the 64-bit HC counters, and must use the 32-bit counters even on Gb links. Ugh. Dave -- [EMAIL PROTECTED] http://net.doit.wisc.edu/~plonka ARS:N9HZF Madison, WI -- Unsubscribe mailto:[EMAIL PROTECTED] Help mailto:[EMAIL PROTECTED] Archive http://www.ee.ethz.ch/~slist/rrd-users WebAdmin http://www.ee.ethz.ch/~slist/lsg2.cgi