Date: Fri, 29 May 2009 17:24:14 +0200 (CEST) From: Harti Brandt <hartmut.brandt@dlr.de> To: smallpox <smallpox@gmail.com> Cc: freebsd-net@freebsd.org Subject: Re: bsnmpd + netsnmp & 64bits counters problem, bce interface problems maybe ? Message-ID: <20090529165809.O23256@beagle.kn.op.dlr.de> In-Reply-To: <4A1FF0B1.8040209@gmail.com> References: <4A1F2706.2080304@gmail.com> <20090529142757.X22933@beagle.kn.op.dlr.de> <4A1FF0B1.8040209@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 29 May 2009, smallpox wrote: s>well, from what im told by snmp people, it's what's happening at that time, so s>up and down is normal... but not at the rate that the non-working one is s>going. and this one's upload and download are spread out normallly, 24 mbit s>out, 2mbit in... s> s>current figures on the messed up system: s> s>[07:25:32 5/29] IF-MIB::ifInOctets.1 /1 sec: 238914024 s>[07:25:32 5/29] IF-MIB::ifOutOctets.1 /1 sec: 223977573 s>[07:25:47 5/29] IF-MIB::ifInOctets.1 /1 sec: 235054494 s>[07:25:47 5/29] IF-MIB::ifOutOctets.1 /1 sec: 222830449 s> s>one of the differences between bsnmpd and net-snmpd is net-snmpd updates every s>15 sec, anyway. see how the in/out are so close? that's totally off. s> s>the driver in question is bce... im not sure Hmm. Why would these numbers go up and down? As I understand it they should go up and wrap at either 32-bit or 64-bit. There are only two cases when they go down: a wrap or a discontinuity, which would be recorded in ifCounterDiscontinuityTime. Just to check: could you please disable TSO on the interface and look what it does? harti s>Harti Brandt wrote: s>> On Thu, 28 May 2009, smallpox wrote: s>> s>> s>hey guys, i've read s>> s> s>> s>> [SNIP] s>> s>> s> s>> s>in comparison to an intel em.. 32bit, it's linked at a gigabit though.. s>> but no s>> s>heavy traffic there. s>> s> s>> s>--BEGIN WORKING s>> s>IF-MIB::ifInOctets.1 /15 sec: 1932426 s>> s>IF-MIB::ifOutOctets.1 /15 sec: 24270520 s>> s>IF-MIB::ifInOctets.1 /15 sec: 2199107 s>> s>IF-MIB::ifOutOctets.1 /15 sec: 28672350 s>> s>IF-MIB::ifInOctets.1 /15 sec: 2049073 s>> s>IF-MIB::ifOutOctets.1 /15 sec: 22716321 s>> s>IF-MIB::ifInOctets.1 /15 sec: 2036279 s>> s>IF-MIB::ifOutOctets.1 /15 sec: 24361972 s>> s>IF-MIB::ifInOctets.1 /15 sec: 2571021 s>> s>IF-MIB::ifOutOctets.1 /15 sec: 32539047 s>> s>IF-MIB::ifInOctets.1 /15 sec: 2416155 s>> s>IF-MIB::ifOutOctets.1 /15 sec: 30571680 s>> s>IF-MIB::ifInOctets.1 /15 sec: 2583795 s>> s>IF-MIB::ifOutOctets.1 /15 sec: 35712392 s>> s>IF-MIB::ifInOctets.1 /15 sec: 2665891 s>> s>IF-MIB::ifOutOctets.1 /15 sec: 34761228 s>> s>IF-MIB::ifInOctets.1 /15 sec: 2249559 s>> s>IF-MIB::ifOutOctets.1 /15 sec: 27438273 s>> s> s>> s>--END WORKING s>> s>> Do I get it wrong or do the 32-bit counters also go up and down? Given that s>> bsnmpd just retrieves the values from the kernel and sends them over SNMP s>> without looking at the values (for the 32-bit counters) this looks rather s>> like a problem in the kernel/driver. Do these drivers perhaps use multiple s>> threads for receiving? s>> s>> harti s>> s>> s> s>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090529165809.O23256>