Date: Mon, 14 Jan 2002 15:00:42 -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: <3C4338EA.1D698EF1@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>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote: > > David Greenman wrote: > > I think counting bytes with a 64bit counter is a perfectly reasonable > > thing to do. I don't think this means that we need to update ALL of the > > counters in the network stack to be 64bits, just the ones that are useful > > to network admins (which is essentially just bytes in/out and packets > > in/out). All the rest can stay 32bit. This isn't that much overhead to > > add and the results are very useful, despite what you and Terry would have > > some people believe. > > How many straws does it take to break a performance camel's back? > > Of course, let us not forget that you are invested in 64 bit, > which won't care about this, anyway. > > I have a hard time paying for something I'm not going to use, > that most people are not going to use, even if it's "only a few > percent here and there". > > It's obvious that he's running a Gigabit ethernet at about 1/4 > wire speed. He claims a 32 bit byte counter overflow in a couple > of minutes, and the theoretical max load limit puts overflow of > such a counter at 32 seconds, so that implies a byte count at > 250Mbit/S. > > 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. > > Let me tell you that, in the field, he is unlikely to find any > colocation facility with the ability to overflow in under 5 > minutes (two OC3's, full saturated by his one box, are only > 100Mbit/S). You *know* this from running the most massive > FTP server on the net for years, right? This is a very nice, big box and it is running at that capacity or more. If you want more details ask DG. He built and installed the box. > > It's perfectly reasonable to recommend that he keep 1024 byte > precision, while maintaining the same accuracy (e.g. using a > modular byte counter, and conting overflows), which would > amplify his "couple minutes" into 34 hours (he's got a bad > lab setup: he should be able to get full wire speed, even out > of a Tigon II, if he tunes correctly). > > Worst case, it's 8 1/2 hours in his lab; in reality, it's > going to be 3 1/2 days in the field, assuming he fully > saturates two OC3's (and assuming he's even permitted to do > that). > > Given the volumes of data he's transitting, I'd up that to > 1Mbyte accuracy, byt keeping the 1 byte precision -- that > gives 1 year in the lab and 10 years in the field until an > overflow. > > Burst throughput, sustained throughput, and the knee between > them will be very close together, and stress-testing should > not be combined with the other two, in any case. I think > that what he's trying to measure is probably a bogus "figure > of merit". > 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. 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 --------------------------------------------------------------------- Nothing is fool proof, because fools are too ingenious. 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?3C4338EA.1D698EF1>