Date: Mon, 14 Jan 2002 18:59:49 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: "M. Warner Losh" <imp@village.org> Cc: bmilekic@technokratis.com, arch@FreeBSD.ORG Subject: Re: 64 bit counters again Message-ID: <3C439B25.27DCCB2D@mindspring.com> References: <20020114105859.A24635@technokratis.com> <3C4305E5.65BB32A6@FreeBSD.org> <20020114114911.A24990@technokratis.com> <20020114.130705.84407599.imp@village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
"M. Warner Losh" wrote: > : You're going to run into the same problem with a 64-bit counter, as > : Terry pointed out. You're just going to end up moving the time it > : takes from 172 seconds to some other, slightly longer, although equally > : unreasonable, time. > > A 64-bit qauntity would take 738734374912 seconds to overflow if the > 32-bit one overflowed in 172 seconds. That strikes me as a reasonable > enough period of time. If I did the math right, that's on the order > of 23 millinia (23425 years). Actually, it's closer to 4000 years, if the counter is for a Gigabit Ethernet running a theoretical max wire speed, where a 32 bit byte counter overflows in 32 seconds (1Gbit/S divided by 8 to get bytes/S). Enough interfaces to saturate PCI-X drops this to 500 years (8Gbit/S). The Apple 802.11e FireWire wireless is already at 5Gbit. The idea that some counter size will never be exceeded by technology by the time it is obsolete is what has people complaining about 32 bit counters in this thread already; are you prepared to make the same base assumption in the choice of 64 bit counters? A terabit network could push a 64 bit counter over in under 6 months. > : Instead of counting bytes, perhaps you should count > : K or M Bytes. Just take the delta you're about to add to your counter > : and divide it by something reasonable before adding it. If you are > : really bent on getting accurate results, maintain a separate counter > : and sum remainders in it. I'm sure you'll get slightly more accurate > : data while not changing all counters to be 64-bits wide on non-64 bit > : platforms (i.e., you'll keep the added execution time local to that > : specific code you're working on). > > That's a whole lot more hair than a 64-bit counter :-). Maybe you > could do it in k bytes, but the typical packet size is on the order of > 1.5k, so you have an error in the neighborhood of 50%. This would be > 0M always. It seems to be that the atomicacy of the updates for any > accumlated remainder scheme would be the same as for a 64-bit counter, > and a whole lot more hair. Please see other posting on how to do modular math to get a differential between bits of precision without losing accuracy. The main win here is that we don't end up with a global counter that requires us to do the "hokey-pokey" to update it because we can't use a single locked instruction to do the add because our processor is only capable of doing that with 32 bit values. Making the same atomicity guarantees for a 64 bit value is not the same as simply doing two instructions; it's a heck of a lot more expensive. -- 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?3C439B25.27DCCB2D>