64 bit counter and Debian (hangs the updating)

[Gorbachov]

Hello Dear,

I have several RHEL 5 servers, the traffic between them is more than 100Mbit that is why I use 64 bit counters for the interface statistics.
The graphs are correct.

I have a server with Debian lenny again connected on 1gb network and the traffic exceeds 100Mbits I decided to switch to 64 bit counters and have correct graphs, but no luck. If I scp 16GB file over the network with speed 40-50MB/s on the graphs just stop updating for this host till it finishes the scp?!
I use SNMP v2 and I have created new graphs to use 64 bit to mbytes/sec

What is wrong where I should start debuging?

Thanks in advance!

[gandalf]

There's a chance that the SNMP UDP packet is dropped due to excessive interface traffic. You may verify this by running a tcpdump (wireshark) on port 161 for that host
Reinhard

[Gorbachov]

I have found out something, all redhat servers are on a blade HP GbE2c swtiches. The server that I have problems is on an HP Procurve swtich. I can't get correct graphs from this swtich too?!

The graph on the port of the GbE2c that is connected to the HP procurve is correct 50-60MB/s but the port on the HP gives me 5-6MB/s. Does this device support 64 bit counters, and could it be the problem of the wrong graphs of the Debian Server?

[gandalf]

I can't verify this assumption. But the fact about different traffic data makes me wonder. Please visit both graphs at Graph Management, switch to debug and post them
Reinhard

[Gorbachov]

I hope this is the staff you asked for:

[gandalf]

Both graphs are printing in orders of [bytes]; that's fine. And I don't see a difference in magnitude, even if both graphs do not fit exactly
Reinhard

[Gorbachov]

I am sorry I did not post a graphs with data transfer higher than 10MB/s.

As you can see on this post, on the graph of the HP Procurve I can't get anything more than 12.86.

[gandalf]

Then, please post the rrdtool graph statements from those graphs like your second to last post
Reinhard

[Gorbachov]

Here you are:

[gandalf]

Again, both graphs do NOT use any scaling factor or calculate bits from bytes. So this is NOT the cause of your problems.
But be careful. As cacti collects data every 300 sec, it is hard to compare peaks, because the may differ to a significant extend if polled at a slightly different time (in fact, I do NOT assume that this explains the difference, but it's hard to tell).
But even the "normal" data seems to be different, even if it's hard to tell from the graphs.
Further debugging requires using data from rrd files, see how they get updated to rrd, see the original data fetched from targets and stuff. Find an intro to this at the 2nd link of my signature. But keep ready for a longer debugging session
Reinhard