From owner-freebsd-net@FreeBSD.ORG Tue Mar 16 03:31:52 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3828B16A4CE for ; Tue, 16 Mar 2004 03:31:52 -0800 (PST) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4735043D31 for ; Tue, 16 Mar 2004 03:31:51 -0800 (PST) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])i2GBVgJ00873; Tue, 16 Mar 2004 12:31:43 +0100 (MET) Date: Tue, 16 Mar 2004 12:31:42 +0100 (CET) From: Harti Brandt To: Brooks Davis In-Reply-To: <20040316014206.GA12382@Odin.AC.HMC.Edu> Message-ID: <20040316122840.E28777@beagle.fokus.fraunhofer.de> References: <2650.192.168.0.200.1079393908.squirrel@192.168.0.1> <2662.192.168.0.200.1079396323.squirrel@192.168.0.1> <2697.192.168.0.200.1079398101.squirrel@192.168.0.1> <20040316014206.GA12382@Odin.AC.HMC.Edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Mike Jakubik cc: net@freebsd.org cc: Max Laier Subject: Re: Byte counters reset at ~4GB X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: harti@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2004 11:31:52 -0000 On Mon, 15 Mar 2004, Brooks Davis wrote: BD>On Mon, Mar 15, 2004 at 07:48:21PM -0500, Mike Jakubik wrote: BD>> Max Laier said: BD>> BD>> > Sure, you measure it ;) ... no, of course it is more expensive to update a BD>> > 64bit counter on a 32bit arch, but the key (once again) is descision: BD>> > While BD>> > (almost) all of the pf counters are 64bit types you can configure it not BD>> > to BD>> > use the loginterface or whatsoever more. So it's up to you: You need 64bit BD>> > counters? You shall have them! You need *fast* 64bit counters? AMD sells BD>> > nice processors (they say)! ... you get the idea. BD>> BD>> Got it. In just curious though... realistically, how big of an impact on BD>> performance is this on a modern CPU? Is it not simply the original 32bit BD>> calculation x 2? BD> BD>No, you have to do overflow handling so that adds some to the cost. BD> BD>I was curious what the actual overhead was so I ran the following BD>program with both uint32_t and uint64_t counters. With 64-bit counters, BD>it was a bit over four times slower on a the dual 2.2GHz Xeon (~2sec vs BD>~8.4sec). On a dual opteron, the 32-bit math had a slight edge, but BD>not much. Intestingly, runtime was longer then on the Xeon (~3.1s for BD>32-bit and ~3.8 for 64-bit.) BD> BD>If you do this test, be sure not to use any optimizer flags or the whole BD>loop gets optimized out. BD> BD>-- Brooks BD> BD>#include BD>#include BD> BD>int BD>main (int argc, char **argv) BD>{ BD> uint32_t j = 0; BD> BD> for (j = 0; j < 1000000000; j++) {} BD> printf("%d\n", j); BD>} Isn't the actual problem the required atomicity? While on 32-bit architectures you can increment a 32-bit value without taking a lock, you need a lock to increment a 64-bit value. harti