Date: Mon, 14 Jan 2002 22:40:56 -0500 From: "James E. Housley" <jeh@FreeBSD.org> To: Terry Lambert <tlambert2@mindspring.com> Cc: David Greenman <dg@root.com>, Bosko Milekic <bmilekic@technokratis.com>, Thomas Hurst <tom.hurst@clara.net>, arch@FreeBSD.org Subject: Re: 64 bit counters again Message-ID: <3C43A4C8.F3DCDAB8@FreeBSD.org> References: <Pine.BSF.4.41.0201132057560.62182-100000@prg.traveller.cz> <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> <3C439832.C52B4379@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote: > > "James E. Housley" wrote: > > > It's just as obvious that, since the counting occurs at > > > interrupt, making atomicity guarantees in the face of hardware > > > interrupts potentially occurring between component instructions > > > is going to be a computationally expensive proposition. > > > > What a minute. If we are in the interrupt routine for this piece of > > hardware and interrupts. Why can't we do the addition during this > > initial poriton while the interrupts are blocked. No one else should be > > incrementing this counter since we are presently servicing it. I do > > understand that in a SMP system there could be a problem with reading > > the data correctly, so this might not work. > > It's a good idea, but it won't work with the direction FreeBSD > is headed with regards to processing interrupts in "ithreads". > The problem is that the actual increment will be in the "top end" > interrupt thread, not in the "bottom end" ISR handler. I have been following the SMPng and was almost sure my suggestion would fail for the reason you stated, but in didn't hurt to much to ask and be sure. > > > 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. > > See the pseudo-code in my previous posting. Having a lower > precision on the reported value is not the same thing as losing I did read that. > accuracy. The smaller ACK and setup packets would be counted > at the byte level by the modular counter, without damaging the > accuracy of the count. In fact, if you were willing to take it > in two pieces at splimp, you could report accuract to the byte > in a 64 bit value, if you were hell-bent on doing that, with the > only real impact being at the time of the report, rather than at > the time of the count (which is what I'm trying to avoid here). > That seems like a resonable solution. All the data would be counted. In the simplest form the number of whole K would be returned with a slight amount of work to get the "full" data when it is needed. I would have no objections to this concept. Jim -- /"\ ASCII Ribbon Campaign . \ / - NO HTML/RTF in e-mail . X - NO Word docs in e-mail . / \ ----------------------------------------------------------------- jeh@FreeBSD.org http://www.FreeBSD.org The Power to Serve jim@TheHousleys.Net http://www.TheHousleys.net jhousley@SimTel.Net http://www.SimTel.Net --------------------------------------------------------------------- If it happens once, it's a bug. If it happens twice, it's a feature. If it happens more than twice, it's windows. -- Luiz de Barros 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?3C43A4C8.F3DCDAB8>