Date: Mon, 14 Jan 2002 18:36:23 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: David Greenman <dg@root.com> Cc: "James E. Housley" <jeh@FreeBSD.org>, Bosko Milekic <bmilekic@technokratis.com>, Thomas Hurst <tom.hurst@clara.net>, arch@FreeBSD.org Subject: Re: 64 bit counters again Message-ID: <3C4395A7.EC3F89A7@mindspring.com> References: <3C41F3FD.4ECC8CD@mindspring.com> <20020113231459.GA30349@voi.aagh.net> <3C42390A.F9E9F533@mindspring.com> <3C42E899.CB21BD0A@FreeBSD.org> <20020114105859.A24635@technokratis.com> <3C4305E5.65BB32A6@FreeBSD.org> <20020114114911.A24990@technokratis.com> <20020114094738.A8955@nexus.root.com> <3C4334A1.6601C5ED@mindspring.com> <3C4338EA.1D698EF1@FreeBSD.org> <20020114115433.D8955@nexus.root.com>
next in thread | previous in thread | raw e-mail | index | archive | help
David Greenman wrote: > >That sounds reasonable. 1024 might be a problem becuase of smaller ACK > >or setup packets, but the concept is reasonable. I would like to know > >the amount of data transmitted and received because that is what we are > >billed on. And at that datarate, to the bit accuracy is crazy. But the > >results should be close enough to reality to be able to trust it with a > >small fudge fact for saftey. > > It's not reasonable because most packets are either small (40 bytes) > or MTU sized. The distribution of sizes is not random and keeping only > 1K internal precision would not result in anything near accurate in terms > of bps. There is a difference between *precision* and *accuracy*. Here is how he could get a 2^10 reduce precision, with 0 reduction in accuracy: He would update his 32 bit byte counter, then he would div it by 1024 (load register from register, shift 10), then add this value to his global counter. Note that he *never* throws away the 10 bits of byte count, he just doesn't externalize it. It gets added to the next set of update values, so at worst, he will be low by a movign average of 512b in any given interval. There would be no loss of overall information, as you seem to be implying with your reference to 40 byte packets. Since the BPS is an *average*, and since the second resolution is *vastly* larger than the modification interval, there should be no problem with this approach. Obviously, the same approach works for any modularl counter modulo, so 20 bits (M instead of K) works, as well, if he needs that resolution because the data rate per second is so high relative to the sampling interval that overflow is ever a risk. Make sense? The point is that the modular counter never needs to be globally locked against contention, so we don't add all the locking that would be necessary for a full 64 bits of precision on a 32 bit architecture. -- 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?3C4395A7.EC3F89A7>