(resending a message that was lost Friday night:)
>> 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.
>
> ~Randy
>
> PS: Here's where you can find linux networking archives:
> linux-net mailing list archives:
> http://marc.theaimsgroup.com/?l=linux-net
> http://groups.google.com/groups?group=mlist.linux.net
> netdev mailing list archives:
> http://oss.sgi.com/projects/netdev/archive/
~Randy
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
