Date: Mon, 14 Jan 2002 02:43:06 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Michal Mertl <mime@traveller.cz> Cc: arch@FreeBSD.ORG Subject: Re: 64 bit counters again Message-ID: <3C42B63A.24CDBC33@mindspring.com> References: <Pine.BSF.4.41.0201140750390.82342-100000@prg.traveller.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C42B63A.24CDBC33>