Interface statistics wrong

Hidde, thanks for the bug.

Does this still happen with latest dapper release?

gnome-nettool has been upgraded twice since you posted this bug. Please provide us some update, ok? Thanks a lot!

it still happens.

Forwarded upstream, http://bugzilla.gnome.org/show_bug.cgi?id=360399

The upstream bug was rejected as being duplicate, and the original one was closed, because it's not a bug from gnome-nettool, but from the kernel. Quoting the mailing list:

>> Surely I'm not the only person to have encountered this issue by now; When
>> the kernel records the tx/rx packet counts and their respective sizes,
>> they rollover very quickly on 32-bit hardware. To put this in better
>> perspective - After roughly 4 Gb worth of network traffic, the Kernel
>> tends to restart at 0 for the rx/tx stats in net_device_stat.

>> Could/should it be changed such that net_device_stat uses larger types for
>> these fields? 4 Gb is not a whole lot of traffic, its discouraging to
>> check ifconfig only a few hours later to find out the kernel has
>> rolled-over several times since you last checked. 32-bit servers with
>> large volumes of traffic are simply swamped with rollovers, rendering any
>> practical use for net_device_stat's rx/tx byte count out of the question.

>> I'm not capable of patching this myself, so it's more along the
>> lines of a comment/suggestion... <smirks>

>> Any insight would be appreciated,

> Lots of replies, eh? or maybe some private ones?

> This has been brought up a few times previously, so you could
> check the archives to see what some other answers are.

> One point is that an SNMP agent could do this for you.
> Are you using one?

> Linux net device counters don't have to track RFCs, but another
> observation is that RFCs require 64-bit ("high capacity")
> counters in cases where a 32-bit counter might overflow within
> 1 hour (IIRC).

> And last, to try to help you understand, one of the reasons
> that it hasn't already been done is that 64-bit
> arithmetic on a 32-bit processor requires using a lock
> to make it atomic, and that's expensive.

Changing Ubuntu task as well ...

I am assigning this bug to the 'ubuntu-kernel-team' per their bug policy. For future reference you can learn more about their bug policy at https://wiki.ubuntu.com/KernelTeamBugPolicies .

The 18 month support period for Edgy Eft 6.10 has reached it's end of life. As a result, we are closing the linux-source-2.6.17 Edgy Eft kernel task.

Hardy Heron 8.04 was recently released. It would be helpful if you could test the new release and verify if this is still an issue - http://www.ubuntu.com/getubuntu/download . You should be able to test your bug using the LiveCD. Please let us know your results. Thanks.

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

Unfortunately this bug report is being closed because we received no response to the last inquiry for information. However, the Intrepid Ibex 8.10 Beta release was most recently announced - http://www.ubuntu.com/testing/intrepid/beta . If you are able to confirm this is still an issue with this most recent release please feel free to reopen this report. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks, Markus

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.