Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 55953 - ifconfig output (RX bytes) wraps
Summary: ifconfig output (RX bytes) wraps
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: net-tools
Version: 7.2
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Phil Knirsch
QA Contact:
: 53158 64213 77969 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2001-11-09 12:03 UTC by Chris Dabrowski
Modified: 2015-03-05 01:09 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2002-02-24 12:54:55 UTC

Attachments (Terms of Use)

Description Chris Dabrowski 2001-11-09 12:03:05 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.78 [en] (X11; U; Linux 2.4.9-7 i686)

Description of problem:
The 'RX bytes' output displayed by 'ifconfig' wraps somewhere above 4062.1

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Type '/sbin/ifconfig eth0'.
2. Receive more that 4096 Mb.
3. Type '/sbin/ifconfig eth0'. The 'RX bytes' counter will show less than
4096 Mb.

Actual Results:

Initial value:

[chris@xxx chris]$  /sbin/ifconfig eth0
eth0      Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx
          inet addr:xx.xx.xx.xx  Bcast:xx.xx.xx.xx  Mask:
          RX packets:5744014 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4816413 errors:0 dropped:0 overruns:0 carrier:0
          collisions:242 txqueuelen:100
          RX bytes:4259431698 (4062.1 Mb)  TX bytes:338292134 (322.6 Mb)
          Interrupt:10 Base address:0x1000

Some time later:

[chris@xxx chris]$  /sbin/ifconfig eth0
eth0      Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx
          inet addr:xx.xx.xx.xx  Bcast:xx.xx.xx.xx  Mask:
          RX packets:6331564 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5384440 errors:0 dropped:0 overruns:0 carrier:0
          collisions:884 txqueuelen:100
          RX bytes:826919889 (788.6 Mb)  TX bytes:382467796 (364.7 Mb)
          Interrupt:10 Base address:0x1000

As you can see 'RX bytes' appears lower but 'TX bytes', 'RX packets',
etc... are all still increasing. The machine hasn't been rebooted between
the two points. (I suspect the problem may also occur with 'TX bytes' at
the same point).

Expected Results:  The 'RX bytes' output should have carried on increasing
in line with the actual data received.

Additional info:

Ethernet card used:

00:11.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone]
        Subsystem: 3Com Corporation 3C905B Fast Etherlink XL 10/100
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr-
+Stepping- SERR+ FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
+<TAbort- <MAbort- >SERR- <PERR-
        Latency: 80 (2500ns min, 2500ns max), cache line size 08
        Interrupt: pin A routed to IRQ 10
        Region 0: I/O ports at 1000 [size=128]
        Region 1: Memory at f4004000 (32-bit, non-prefetchable) [size=128]
        Expansion ROM at <unassigned> [disabled] [size=128K]
        Capabilities: <available only to root>

Comment 1 Phil Knirsch 2002-02-24 12:53:25 UTC
The problem is rooted deeper in the system as you might think. It all boils down
to the kernel collecting the stats with unsigned long only, which are generally
only 32bit and therefore overflow at approx 4GB.

I'll ask our kernel folks if we can change this without breaking anything else
horribly (this bug actually bugged me for a while, too, especially if you really
want to generate reliable statistics from your interfaces).

I'll let you know more via this bugzilla entry.

Read ya, Phil

Comment 2 Phil Knirsch 2002-02-24 12:54:50 UTC
*** Bug 53158 has been marked as a duplicate of this bug. ***

Comment 3 Phil Knirsch 2002-02-25 13:10:13 UTC
OK, i talked with our kernel folks. The problem is that 64bit counters in the
kernel is not a good idea on 32bit archs like i386 as every update to the stat
variables would need a lock around them (see SMP).

This would hurt network performance more than would be gained by this 'cosmetic'
change, so the stats in the kernel will stay as they are.

IIRC there are packages that actually do accounting as well which should
circumvent this problem.

Read ya, Phil

Comment 4 Phil Knirsch 2002-04-29 12:48:07 UTC
*** Bug 64213 has been marked as a duplicate of this bug. ***

Comment 5 Phil Knirsch 2002-11-27 10:54:18 UTC
*** Bug 77969 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.