Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 29 May 2009 10:24:29 -0700
From:      smallpox <smallpox@gmail.com>
To:        Harti Brandt <harti@freebsd.org>
Cc:        freebsd-net@freebsd.org
Subject:   Re: bsnmpd + netsnmp & 64bits counters problem, bce interface problems maybe ?
Message-ID:  <4A201A4D.1000301@gmail.com>
In-Reply-To: <20090529165809.O23256@beagle.kn.op.dlr.de>
References:  <4A1F2706.2080304@gmail.com> <20090529142757.X22933@beagle.kn.op.dlr.de> <4A1FF0B1.8040209@gmail.com> <20090529165809.O23256@beagle.kn.op.dlr.de>

next in thread | previous in thread | raw e-mail | index | archive | help
me: is it supposed to be sequential ?
me: from low to high ?
netsnmpguy: no, it's the difference between on poll period to the next

he did admit that he doesn't monitor high speed networks so he can't be 
too sure.

ifconfig bce0 -tso

bce0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        
options=bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM>



[10:13:21 5/29] IF-MIB::ifInOctets.1 /1 sec: 157715996
[10:13:21 5/29] IF-MIB::ifOutOctets.1 /1 sec: 161365331
[10:13:36 5/29] IF-MIB::ifInOctets.1 /1 sec: 181177076
[10:13:36 5/29] IF-MIB::ifOutOctets.1 /1 sec: 172743760
[10:13:51 5/29] IF-MIB::ifInOctets.1 /1 sec: 173974646
[10:13:51 5/29] IF-MIB::ifOutOctets.1 /1 sec: 179701472

and

[10:21:06 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 189562690
[10:21:06 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 193086153
[10:21:21 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 162102286
[10:21:21 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 174412564
[10:21:36 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 163761580
[10:21:36 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 178587294

then i kill snmpd and launch bsnmpd.. and i know it's growing but 
probably just like everything else, it's not going to be at 90mbit already.

[10:21:52 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 824582
[10:21:52 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 726172
[10:21:52 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 810400
[10:21:52 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 714542
[10:21:53 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 8073610
[10:21:53 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 8263915
[10:21:54 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 8950868
[10:21:54 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 10064090
[10:21:55 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 8734086
[10:21:55 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 9477418
[10:21:56 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 8764476
[10:21:56 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 9738831
[10:21:57 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 9398614
[10:21:57 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 9894332
[10:21:58 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 9497888
[10:21:58 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 10337890
[10:21:59 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 10057064
[10:21:59 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 10657596
[10:22:00 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 10379198
[10:22:00 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 11772401
[10:22:01 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 10863412
[10:22:01 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 12284506
[10:22:02 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 10204962
[10:22:02 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 10745774


bsnmpd does it every second.

also, as far as this "        
options=bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM>"

jumbo is disabled on the switch.

in comparison to another gigabit, (em0) on that switch.         
options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>

they're both at MTU 1500 though.

thanks

Harti Brandt wrote:
> 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?4A201A4D.1000301>