bsnmpd + netsnmp & 64bits counters problem, bce interface problems maybe ?

Fri May 29 18:56:33 UTC 2009

On Fri, 29 May 2009, smallpox wrote:

s>me: is it supposed to be sequential ?
s>me: from low to high ?
s>netsnmpguy: no, it's the difference between on poll period to the next

The value of ifOutOctets is not the difference between poll periods but it 
is just the polled value of the octets that are sent. If you make sure 
that your poll period is short enough (bsnmpd tries to make this sure for 
the 64-bit counters by adjusting its own poll interval to the speed of the 
fastest network). Of course it will wrap, but that's the only time it can 
go down (except for discontinuities which happen if you restart the daemon 
or the OS). So if you have, for example, a gigabit interface, the output 
octet counter wraps at minimum every 35 seconds. If you poll every second 
you should see the counter going down not more than every 35 polls.

So what are the values you are printing below? The differences between two 
polls or the poll values?

harti

s>
s>he did admit that he doesn't monitor high speed networks so he can't be too
s>sure.
s>
s>ifconfig bce0 -tso
s>
s>bce0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
s>       options=bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM>
s>
s>
s>
s>[10:13:21 5/29] IF-MIB::ifInOctets.1 /1 sec: 157715996
s>[10:13:21 5/29] IF-MIB::ifOutOctets.1 /1 sec: 161365331
s>[10:13:36 5/29] IF-MIB::ifInOctets.1 /1 sec: 181177076
s>[10:13:36 5/29] IF-MIB::ifOutOctets.1 /1 sec: 172743760
s>[10:13:51 5/29] IF-MIB::ifInOctets.1 /1 sec: 173974646
s>[10:13:51 5/29] IF-MIB::ifOutOctets.1 /1 sec: 179701472
s>
s>and
s>
s>[10:21:06 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 189562690
s>[10:21:06 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 193086153
s>[10:21:21 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 162102286
s>[10:21:21 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 174412564
s>[10:21:36 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 163761580
s>[10:21:36 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 178587294
s>
s>then i kill snmpd and launch bsnmpd.. and i know it's growing but probably
s>just like everything else, it's not going to be at 90mbit already.
s>
s>[10:21:52 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 824582
s>[10:21:52 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 726172
s>[10:21:52 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 810400
s>[10:21:52 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 714542
s>[10:21:53 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 8073610
s>[10:21:53 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 8263915
s>[10:21:54 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 8950868
s>[10:21:54 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 10064090
s>[10:21:55 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 8734086
s>[10:21:55 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 9477418
s>[10:21:56 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 8764476
s>[10:21:56 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 9738831
s>[10:21:57 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 9398614
s>[10:21:57 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 9894332
s>[10:21:58 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 9497888
s>[10:21:58 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 10337890
s>[10:21:59 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 10057064
s>[10:21:59 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 10657596
s>[10:22:00 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 10379198
s>[10:22:00 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 11772401
s>[10:22:01 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 10863412
s>[10:22:01 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 12284506
s>[10:22:02 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 10204962
s>[10:22:02 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 10745774
s>
s>
s>bsnmpd does it every second.
s>
s>also, as far as this "
s>options=bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM>"
s>
s>jumbo is disabled on the switch.
s>
s>in comparison to another gigabit, (em0) on that switch.
s>options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
s>
s>they're both at MTU 1500 though.
s>
s>thanks
s>
s>Harti Brandt wrote:
s>> On Fri, 29 May 2009, smallpox wrote:
s>> 
s>> s>well, from what im told by snmp people, it's what's happening at that
s>> time, so
s>> s>up and down is normal... but not at the rate that the non-working one is
s>> s>going. and this one's upload and download are spread out normallly, 24
s>> mbit
s>> s>out, 2mbit in...
s>> s>
s>> s>current figures on the messed up system:
s>> s>
s>> s>[07:25:32 5/29] IF-MIB::ifInOctets.1 /1 sec: 238914024
s>> s>[07:25:32 5/29] IF-MIB::ifOutOctets.1 /1 sec: 223977573
s>> s>[07:25:47 5/29] IF-MIB::ifInOctets.1 /1 sec: 235054494
s>> s>[07:25:47 5/29] IF-MIB::ifOutOctets.1 /1 sec: 222830449
s>> s>
s>> s>one of the differences between bsnmpd and net-snmpd is net-snmpd updates
s>> every
s>> s>15 sec, anyway. see how the in/out are so close? that's totally off.
s>> s>
s>> s>the driver in question is bce... im not sure
s>> 
s>> Hmm. Why would these numbers go up and down? As I understand it they should
s>> go up and wrap at either 32-bit or 64-bit. There are only two cases when
s>> they go down: a wrap or a discontinuity, which would be recorded in
s>> ifCounterDiscontinuityTime.
s>> 
s>> Just to check: could you please disable TSO on the interface and look what
s>> it does?
s>> 
s>> harti
s>> 
s>> s>Harti Brandt wrote:
s>> s>> On Thu, 28 May 2009, smallpox wrote:
s>> s>> s>> s>hey guys, i've read
s>> s>> s>
s>> s>> s>> [SNIP]
s>> s>> s>> s>
s>> s>> s>in comparison to an intel em.. 32bit, it's linked at a gigabit
s>> though..
s>> s>> but no
s>> s>> s>heavy traffic there.
s>> s>> s>
s>> s>> s>--BEGIN WORKING
s>> s>> s>IF-MIB::ifInOctets.1 /15 sec: 1932426
s>> s>> s>IF-MIB::ifOutOctets.1 /15 sec: 24270520
s>> s>> s>IF-MIB::ifInOctets.1 /15 sec: 2199107
s>> s>> s>IF-MIB::ifOutOctets.1 /15 sec: 28672350
s>> s>> s>IF-MIB::ifInOctets.1 /15 sec: 2049073
s>> s>> s>IF-MIB::ifOutOctets.1 /15 sec: 22716321
s>> s>> s>IF-MIB::ifInOctets.1 /15 sec: 2036279
s>> s>> s>IF-MIB::ifOutOctets.1 /15 sec: 24361972
s>> s>> s>IF-MIB::ifInOctets.1 /15 sec: 2571021
s>> s>> s>IF-MIB::ifOutOctets.1 /15 sec: 32539047
s>> s>> s>IF-MIB::ifInOctets.1 /15 sec: 2416155
s>> s>> s>IF-MIB::ifOutOctets.1 /15 sec: 30571680
s>> s>> s>IF-MIB::ifInOctets.1 /15 sec: 2583795
s>> s>> s>IF-MIB::ifOutOctets.1 /15 sec: 35712392
s>> s>> s>IF-MIB::ifInOctets.1 /15 sec: 2665891
s>> s>> s>IF-MIB::ifOutOctets.1 /15 sec: 34761228
s>> s>> s>IF-MIB::ifInOctets.1 /15 sec: 2249559
s>> s>> s>IF-MIB::ifOutOctets.1 /15 sec: 27438273
s>> s>> s>
s>> s>> s>--END WORKING
s>> s>> s>> Do I get it wrong or do the 32-bit counters also go up and down?
s>> Given that
s>> s>> bsnmpd just retrieves the values from the kernel and sends them over
s>> SNMP
s>> s>> without looking at the values (for the 32-bit counters) this looks
s>> rather
s>> s>> like a problem in the kernel/driver. Do these drivers perhaps use
s>> multiple
s>> s>> threads for receiving?
s>> s>> s>> harti
s>> s>> s>>   s>
s>> s>
s>> 
s>>   
s>
s>