Thanks, sounds good. My RRD's were created with "Interval: 5" and they still have "step = 300" when I do "rrdtool info", but the mrtg-instance runs every 1 minute now so this should give me quite accurate values; this isn't used for any accounting or smth similar so some errors are ok. The traffic I expect isn't much higher than 200 MBit so it should work in this case for me. There's also a newer software-version of the 3Com 4900 available but in the release notes there's nothing about snmpv2... Easiest thing would be to get this customer buy a Cisco ;)
As we're talking about counter-warps ;) Another thing I already asked some time ago on the list, I still haven't completely understood on which criteria mrtg relies to detect a counter wrap. Because I have another problem, much more annoying (because this data IS used for accounting), that spikes are generated for most graphs when a device reloads. I wrote debugs now the last few weeks but had no time to analyze in detail so far; it seems that for some reason mrtg thinks the counter wrapped instead of counting from zero after the reload. I found an intersting post from you from Dec 2001 which exactly describes how it should be handled (with looking on the uptime of the device) but as far as I can see mrtg doesn't do this (??) If yes, can you probably point me to the line to comment out to *prevent* mrtg from wrapping counters at all. (I'd go to patch one mrtg as I never have counter-wraps on 99,99% of the devices because the traffic is either low or using 64bit-counters on the cisco-boxes) [rrd-users] Re: Dealing with counter resets http://www.ee.ethz.ch/~slist/rrd-users/msg03695.html I found in mrtg on line 328: --- cut --- if ($inlast < 0) { $inlast += 2**31; # this is likely to be a broken snmp counter ... lets compensate --- cut --- This looks for me like the part which creates my spikes, but should never get executed as I use rrdtool for all graphs ?? So is this "feature" creating my spikes probably in rrdtool self (using RRDtool 1.0.41) and I was looking on the wrong thing (mrtg) all the time. Michael -----Original Message----- From: Alex van den Bogaerdt [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 27, 2003 1:13 PM To: [EMAIL PROTECTED] Subject: [mrtg] Re: MRTG to monitor Gigabit-ethernet with counter32 and interval: 1 On Tue, May 27, 2003 at 12:54:47PM +0200, Michael Markstaller wrote: > Just a quick question, I have to monitor a 3Com Superstack 4900 GE-switch > which seems to have no SNMP-v2c at all and so no 64Bit-counters ifHC*Octets. > So far so bad, I understand the whole problem; when traffic hits 114 MBit, > counters wrap etc.. The problem is slightly different: above 114 Mbps and with a 5-minute interval, the wrapping occurs so often that mrtg doesn't find a wrap. counter increase real value seen increase 10 12 2 2+2^32 14 2 2+2^32 By polling more often, this happens: counter increase real value seen increase 10 11+2^31 1+2^31 1+2^31 (extra poll) 12 1+2^31 1+2^31 13+2^31 1+2^31 1+2^31 (extra poll) 14 1+2^31 1+2^31 Polling more often introduces more error. Suppose the timing accuracy is 1 second. Normally this results in an error of ~ 1:300. If you're going to poll every 1 second then this results in an error of 1:1. Not good. Specifying an interval of 300 seconds in rrdtool and polling every minute (or so) will work and should result in better handling of the frequent wraps but do keep the error in mind. cheers, Alex -- Unsubscribe mailto:[EMAIL PROTECTED] 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:[EMAIL PROTECTED] 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
