Bug 55953

Summary: ifconfig output (RX bytes) wraps
Product: [Retired] Red Hat Linux Reporter: Chris Dabrowski <chris-redhat.com>
Component: net-toolsAssignee: Phil Knirsch <pknirsch>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 7.2CC: rvokal
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2002-02-24 12:54:55 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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
Mb.

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


How reproducible:
Always

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:255.255.255.248
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          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:255.255.255.248
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          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]
(rev
+24)
        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. ***