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

[smallpox]

well, from what im told by snmp people, it's what's happening at that 
time, so up and down is normal... but not at the rate that the 
non-working one is going. and this one's upload and download are spread 
out normallly, 24 mbit out, 2mbit in...

current figures on the messed up system:

[07:25:32 5/29] IF-MIB::ifInOctets.1 /1 sec: 238914024
[07:25:32 5/29] IF-MIB::ifOutOctets.1 /1 sec: 223977573
[07:25:47 5/29] IF-MIB::ifInOctets.1 /1 sec: 235054494
[07:25:47 5/29] IF-MIB::ifOutOctets.1 /1 sec: 222830449

one of the differences between bsnmpd and net-snmpd is net-snmpd updates 
every 15 sec, anyway. see how the in/out are so close? that's totally off.

the driver in question is bce... im not sure

thanks

Harti Brandt wrote:
> On Thu, 28 May 2009, smallpox wrote:
>
> s>hey guys, i've read
> s>
>
> [SNIP]
>
> s>
> s>in comparison to an intel em.. 32bit, it's linked at a gigabit though.. but no
> s>heavy traffic there.
> s>
> s>--BEGIN WORKING
> s>IF-MIB::ifInOctets.1 /15 sec: 1932426
> s>IF-MIB::ifOutOctets.1 /15 sec: 24270520
> s>IF-MIB::ifInOctets.1 /15 sec: 2199107
> s>IF-MIB::ifOutOctets.1 /15 sec: 28672350
> s>IF-MIB::ifInOctets.1 /15 sec: 2049073
> s>IF-MIB::ifOutOctets.1 /15 sec: 22716321
> s>IF-MIB::ifInOctets.1 /15 sec: 2036279
> s>IF-MIB::ifOutOctets.1 /15 sec: 24361972
> s>IF-MIB::ifInOctets.1 /15 sec: 2571021
> s>IF-MIB::ifOutOctets.1 /15 sec: 32539047
> s>IF-MIB::ifInOctets.1 /15 sec: 2416155
> s>IF-MIB::ifOutOctets.1 /15 sec: 30571680
> s>IF-MIB::ifInOctets.1 /15 sec: 2583795
> s>IF-MIB::ifOutOctets.1 /15 sec: 35712392
> s>IF-MIB::ifInOctets.1 /15 sec: 2665891
> s>IF-MIB::ifOutOctets.1 /15 sec: 34761228
> s>IF-MIB::ifInOctets.1 /15 sec: 2249559
> s>IF-MIB::ifOutOctets.1 /15 sec: 27438273
> s>
> s>--END WORKING
>
> Do I get it wrong or do the 32-bit counters also go up and down? Given 
> that bsnmpd just retrieves the values from the kernel and sends them over 
> SNMP without looking at the values (for the 32-bit counters) this looks 
> rather like a problem in the kernel/driver. Do these drivers perhaps use 
> multiple threads for receiving?
>
> harti
>
>