Date: Tue, 20 May 2003 11:50:40 -0400 From: Chuck Swiger <cswiger@mac.com> To: freebsd-stable@freebsd.org Subject: Re: 4GB limit with netstat Message-ID: <3ECA4ED0.8030709@mac.com> In-Reply-To: <xzpof1x3mgb.fsf@flood.ping.uio.no> References: <200305200624.QAA20280@lightning.itga.com.au> <001301c31e9d$d5523860$0101000a@vx> <xzpof1x3mgb.fsf@flood.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
Dag-Erling Smorgrav wrote:
[ ... ]
> I think "never" is a safe bet.
It's hard to change the existing if_data structure without breaking
things, understood. However, there are still some things that could be
done to make the situation better, I think.
One would be to test for overflow when incrementing the counters and at
least log (via the kernel message buffer) when a counter value has
wrapped. This should be easy to do, relatively cheap in terms of
overhead-- most architectures have a conditional branch on the V flag--
and would be helpful for quantifying how frequently this situation happens.
It might be reasonable to do something like zero all of the counters
when overflow happens (logging their values to dmesg, first), so that
their relative values remain meaningful for the sake of comparision.
And if the old stats are logged, it would be possible to accumulate
those entries in a program using 64-bit counters and obtain the complete
stats if one needed to.
Or one could even keep track of the number of times a 32-bit counter has
overflowed, which suspiciously resembles keeping the high bits of a
64-bit counter in a second 32-bit value, which could then be appended to
the end of (struct if_data) without breaking backwards compatibility.
ifi_ibytes_msb and ifi_obytes_msb...?
While I'm thinking about it, is there a reason why nobody seems to put a
version # into structures?
-Chuck
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3ECA4ED0.8030709>