From owner-freebsd-arch Mon Jan 14 2:43:15 2002 Delivered-To: freebsd-arch@freebsd.org Received: from falcon.prod.itd.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id 7DD3437B41A for ; Mon, 14 Jan 2002 02:43:11 -0800 (PST) Received: from pool0023.cvx22-bradley.dialup.earthlink.net ([209.179.198.23] helo=mindspring.com) by falcon.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16Q4a4-0007Td-00; Mon, 14 Jan 2002 02:43:08 -0800 Message-ID: <3C42B63A.24CDBC33@mindspring.com> Date: Mon, 14 Jan 2002 02:43:06 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Michal Mertl Cc: arch@FreeBSD.ORG Subject: Re: 64 bit counters again References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Michal Mertl wrote: > > 1) It makes counting slower on 32 bit processors. > > How much slower? 64 bit addition on i386 is only 2 simple instructions > instead of 1 for 32 bit. Plus the carry, plus the atomicity guarantees that you have to be able to make so that the value is not examined if a context switch is forced between those instructions, or an interrupt (or higher priority interrupt) occurs. > > 2) The values are not accessible from SNMP, which is > > limited to 32 bit counters. > > Not true. You do better check things before explaining them to anyone. I already commented that it was a limitation of my SNMP console, more than a day before you wrote this. > > So it seems to me that the utility of this on 32 bit machines > > is incredibly limited (e.g. shell programs). > > I don't see that much utility either, only to have right values. But I got > at least one email asking for the patch because the guy uses the counters. > He said they overflow in several minutes for him so are really useless. I would argue that he should be counting packets instead of bytes, or packets per second, or something other than what he is counting, if he is overflowing that quickly. A 64 bit counter gives us 8000 years, if it overflows in a minute, and that coupled with Moore's law applied to network speeds gives us about 2 years before the 64 bit counters are useless for the same reasons. I will tell you that at ClickArray, the logging overhead, which is in the same general category as these counters ("administrative eye candy for humans that has no bearing on the functionality of the technology itself, when it comes to whether or not you can push packets) grew into over 30% of the overall overhead for the product, even after a zero system call boundary transition clock function and other nifty optimizations. I guess if you are a telephone company, hell bent on charging per packet, you're willing to take 30% of your actual real capability, and sink it into accounting instead of getting work done. > > PS: FWIW, I agree that these things should be 64 bits on > > 64 bit architectures, even if they can only export > > the low 32 bits for SNMP. > > I think some counters are already 64 bit on 64 bit architectures, > because they are defined as u_long which is (I believe) 64 bit. The blythe thing to say at this point is "use 64 bit hardware"... 8-) 8-). Not a good answer, I know. > The most importatnt thing is that I don't believe the operations > are expensive (when not using locked atomic ops at least). I think the operations would have to be locked. A received bad packet checksum counter (for example) would have to be accessed at interrupt in the driver. Locking and atomicity are problematic, and are guaranteed to add overhead (better to keep it per interface [==per device instance], and total on demand, actually). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message