ifconfig - Trafficcounter resets at 4GiB

[whirpool]

Heya everyone!

When, out of curiosity, i wanted to check how much traffic was generated by my Pi i found some very small numbers.

I stumbled upon this a while ago but finaly found the time to investigate and it seems that the RX/TX-Bytes of the eth0 Interface are getting resetted when reaching the 4GiB mark.

I wrote a little script that runs every 60s and saves the output of 'ifconfig eth0 | grep -i "bytes"'.

Code: Select all

#!/bin/bash

datafile=iftest-data.$(date +"%Y-%m-%d.%T").txt
touch ./$datafile

while [ 1 -gt 0 ]; do
	datetime=$(date +"%Y-%m-%d.%T")
	traffic=`ifconfig eth0 | grep -i "bytes"`
	echo $datetime $traffic
	echo $datetime $traffic >> ./$datafile
	sleep 60
done

When checking back after a few hours i found this:

Code: Select all

(....)
2012-12-30.11:54:42 RX bytes:2242101595 (2.0 GiB) TX bytes:4281750626 (3.9 GiB)
2012-12-30.11:55:42 RX bytes:2244385696 (2.0 GiB) TX bytes:44203959 (42.1 MiB)
(....)
2012-12-30.12:48:57 RX bytes:4294515432 (3.9 GiB) TX bytes:3412439252 (3.1 GiB)
2012-12-30.12:49:57 RX bytes:1874946 (1.7 MiB) TX bytes:3481206666 (3.2 GiB)
(....)

Above: in the first two lines the TX gets reset and in the last two lines the RX.

This is from a Rev1 Pi with 256MB RAM running Raspbian and was last updated on Dec.26th (4days ago).

Now.. is ifconfig working as intended, is it a feature or a bug?

Give me a howler if you should need any more information to solve this 'mystery'.

Greetings,
whirpool

[joan]

Presumably the count is held in a 32 bit word. 2^32 is 4294967296 or 4GB. You'll have to cater for the wrap around in your scripts.

[Joe Schmoe]

How many people here know what the maximum amount of uptime there can be on (32 bit) Linux systems?

[MaxK1]

I think the limiting factor is going to be either a hardware failure or power to the system...

[obcd]

Such a wrap is unavoidable. As it seem to happen at 32 bit, you still can calculate an average troughput for several hours. If the new number is smaller than previous one, either the maximum was reached or the system was restarted. It wouldn't suprise me that other linux distro's show the same behavour.

[joan]

My router (Linux based) does the same.

[efflandt]

According to a quick web search, 32-bit uptime rolls over at 496 or 497 days. I have an old Celeron 300 computer with 160 MB RAM that ran 24/7 without rebooting for 5 yrs from July 2006 through July 2011. The reason I shut it down then was a long power failure (14 hrs). In 5 years I did notice its uptime rolling over more than once. It did not need to be shut down for updates because its Linux version is obsolete.

Code: Select all

efflandt@realhost:~> ls -l /etc/*release
-rw-r--r--    1 root     root           36 2003-03-18 11:48 /etc/SuSE-release
efflandt@realhost:~> cat /etc/*release
SuSE Linux 8.2 (i586)
VERSION = 8.2
efflandt@realhost:~> free
             total       used       free     shared    buffers     cached
Mem:        158808     155704       3104          0      49596      16716
-/+ buffers/cache:      89392      69416
Swap:       370400        384     370016

Currently it has only been up 50 days due to an SUV driving straight on a curve, through the mens room of a church and ending up on its roof, knocking out power and reminding me that I needed new UPS batteries. I wonder if they were texting while driving.

64-bit systems hold bigger numbers:

Code: Select all

efflandt@XPS8100-1204:~$ ifconfig wlan0
wlan0     Link encap:Ethernet  HWaddr 78:e4:00:26:b8:ac  
          inet addr:172.16.0.50  Bcast:172.16.0.255  Mask:255.255.255.0
          inet6 addr: fe80::7ae4:ff:fe26:b8ac/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:38944156 errors:0 dropped:20 overruns:0 frame:0
          TX packets:46529950 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:13315312114 (13.3 GB)  TX bytes:28282460334 (28.2 GB)

[Joe Schmoe]

[quote="efflandt"]According to a quick web search, 32-bit uptime rolls over at 496 or 497 days.[quote]

The correct figure is:

497.10269629629629629629

days. But I wonder how many people know how/why to derive that figure.

[rurwin]

Reminds me of the bug in Windows 95 that caused it to crash when a 32-bit count of milliseconds wrapped around (about 49 days). It took them until 2000 to realise there was a problem, presumably because no Windows computer before that survived for 49 days before crashing for other reasons.

[Joe Schmoe]

Reminds me of the bug in Windows 95 that caused it to crash when a 32-bit count of milliseconds wrapped around (about 49 days). It took them until 2000 to realise there was a problem, presumably because no Windows computer before that survived for 49 days before crashing for other reasons.

That's a good line, and of course could well be true - given that Windows 95/98 was never intended as a server (in any sense of the word) OS, so there's not really any reason for anyone to leave it up overnight/all-the-time.

Still, I'm a little surprised at that. I'll have to test it.

Expect to hear back from me in late February...

[rurwin]

http://support.microsoft.com/kb/216641

I was six months out; not 2000 -- June 1999, same difference

It's not actually very surprising that it took so long. There would have been a very small number of computers left on that long and a lot of background noise due to various other issues that would arise over that time. It would take a significant number of reports before the significance of "not quite 50 days" became obvious.

[whirpool]

Presumably the count is held in a 32 bit word. 2^32 is 4294967296 or 4GB. You'll have to cater for the wrap around in your scripts.

Sadly i think you are right and the 32bit limit causes the reset.
Thx for pointing me in the right direction!

greetings,
whirpool

[SN]

According to a quick web search, 32-bit uptime rolls over at 496 or 497 days.

The correct figure is:

497.10269629629629629629

days. But I wonder how many people know how/why to derive that figure.

divide it into 4*1024*1024*1024 and you get the number of hundredths-of-a-second in a day!

[SN]

we're someway behind the OpenVMS Cluster continuous uptime record which stands at (as of 8.02AM GMT on Friday 11th) 17 Years 6 Days 21 Hours 47 Minutes
See http://uptimes-project.org/hosts/view/150