From owner-freebsd-stable@FreeBSD.ORG Tue May 20 08:50:45 2003 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9456F37B401 for ; Tue, 20 May 2003 08:50:45 -0700 (PDT) Received: from pop016.verizon.net (pop016pub.verizon.net [206.46.170.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id A0C5243F93 for ; Tue, 20 May 2003 08:50:44 -0700 (PDT) (envelope-from cswiger@mac.com) Received: from mac.com ([129.44.60.214]) by pop016.verizon.net (InterMail vM.5.01.05.33 201-253-122-126-133-20030313) with ESMTP id <20030520155043.ZEVK3199.pop016.verizon.net@mac.com> for ; Tue, 20 May 2003 10:50:43 -0500 Message-ID: <3ECA4ED0.8030709@mac.com> Date: Tue, 20 May 2003 11:50:40 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <200305200624.QAA20280@lightning.itga.com.au> <001301c31e9d$d5523860$0101000a@vx> In-Reply-To: X-Enigmail-Version: 0.75.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at pop016.verizon.net from [129.44.60.214] at Tue, 20 May 2003 10:50:43 -0500 Subject: Re: 4GB limit with netstat X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2003 15:50:45 -0000 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