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>
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
*** Bug 53158 has been marked as a duplicate of this bug. ***
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
*** Bug 64213 has been marked as a duplicate of this bug. ***
*** Bug 77969 has been marked as a duplicate of this bug. ***