From owner-freebsd-arch Tue Jan 15 13:44:15 2002 Delivered-To: freebsd-arch@freebsd.org Received: from netau1.alcanet.com.au (ntp.alcanet.com.au [203.62.196.27]) by hub.freebsd.org (Postfix) with ESMTP id AE40437B416 for ; Tue, 15 Jan 2002 13:44:10 -0800 (PST) Received: from mfg1.cim.alcatel.com.au (mfg1.cim.alcatel.com.au [139.188.23.1]) by netau1.alcanet.com.au (8.9.3 (PHNE_22672)/8.9.3) with ESMTP id HAA01765; Wed, 16 Jan 2002 07:26:03 +1100 (EDT) Received: from gsmx07.alcatel.com.au by cim.alcatel.com.au (PMDF V5.2-32 #37641) with ESMTP id <01KD4PV219U8VFMGZL@cim.alcatel.com.au>; Wed, 16 Jan 2002 07:26:19 +1100 Received: (from jeremyp@localhost) by gsmx07.alcatel.com.au (8.11.6/8.11.6) id g0FKQ0572158; Wed, 16 Jan 2002 07:26:00 +1100 Content-return: prohibited Date: Wed, 16 Jan 2002 07:26:00 +1100 From: Peter Jeremy Subject: Re: 64 bit counters again In-reply-to: <20020114201018.GA64041@voi.aagh.net>; from tom.hurst@clara.net on Mon, Jan 14, 2002 at 08:10:18PM +0000 To: Thomas Hurst Cc: arch@FreeBSD.ORG Mail-Followup-To: Thomas Hurst , arch@FreeBSD.ORG Message-id: <20020116072600.A72142@gsmx07.alcatel.com.au> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.5i References: <3C41F3FD.4ECC8CD@mindspring.com> <20020113231459.GA30349@voi.aagh.net> <3C42390A.F9E9F533@mindspring.com> <3C42E899.CB21BD0A@FreeBSD.org> <3C431EE5.1CFF557B@mindspring.com> <20020114201018.GA64041@voi.aagh.net> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Jan 14, 2002 at 08:10:18PM +0000, Thomas Hurst wrote: >I'm just interested in how much bandwidth I'm using, but if the counters >are going to overflow this easily, they cease being terribly useful, >unless I'm going to actively count them and watch for overflows in >userspace. All this needs is a counter big enough to represent the number of bits/bytes/whatever transmitted/received/whatever during the sample period. It doesn't matter if the absolute counter value overflows during the sample period (as long as it doesn't overflow more than once). [This assumes an unsigned 2's complement representation with arithmetic overflows ignored - which covers virtually all current hardware]. For example, the following function will report the average bandwidth since it was last called: static ulong prev_val; struct { ulong low, high; } total_val; double bytes_per_second() { static timeval prev_time; timeval cur_time; ulong cur_val; double bps; cur_val = read_counter(); gettimeofday(&cur_time, NULL); bps = (double)(cur_val - prev_val) / (cur_time.tv_sec - prev_time.tv_sec + (cur_time.tv_usec - prev_time.tv_usec) / 1e6); #ifdef CALCULATE_TOTAL_VALUE total_val.low = cur_val; if (cur_val < prev_val) total_val.high++; #endif prev_time = cur_time; prev_val = cur_val; return (bps); } The optional code inside CALCULATE_TOTAL_VALUE will give you an accurate total units count with an extended range as long as the sample rate is high enough. >I'm not really bothered if they're totally accurate, since they're just >a guide - how about a float that counts kb? ;) Two major downsides: 1) The FreeBSD kernel (as well as most other Un*x kernels) avoid the use of FP for various reasons. The use of FP within interrupt handlers would seriously affect interrupt latency - by a factor or two or more. 2) FP trades accuracy for range. After a while your counters will lose more and more precision and eventually stop counting at all: 33554432.0f + 1.0f == 33554432.0f Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message