From owner-freebsd-net@FreeBSD.ORG Fri May 29 15:24:15 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 084C11065670 for ; Fri, 29 May 2009 15:24:15 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp1.dlr.de (smtp1.dlr.de [129.247.252.32]) by mx1.freebsd.org (Postfix) with ESMTP id 8EC968FC13 for ; Fri, 29 May 2009 15:24:14 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from beagle.kn.op.dlr.de ([129.247.178.136]) by smtp1.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 May 2009 17:24:12 +0200 Date: Fri, 29 May 2009 17:24:14 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: smallpox In-Reply-To: <4A1FF0B1.8040209@gmail.com> Message-ID: <20090529165809.O23256@beagle.kn.op.dlr.de> References: <4A1F2706.2080304@gmail.com> <20090529142757.X22933@beagle.kn.op.dlr.de> <4A1FF0B1.8040209@gmail.com> X-OpenPGP-Key: harti@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 29 May 2009 15:24:12.0884 (UTC) FILETIME=[8548D940:01C9E071] Cc: freebsd-net@freebsd.org Subject: Re: bsnmpd + netsnmp & 64bits counters problem, bce interface problems maybe ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2009 15:24:15 -0000 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>