Date: Mon, 14 Jan 2002 11:42:25 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: David Greenman <dg@root.com> Cc: Bosko Milekic <bmilekic@technokratis.com>, "James E. Housley" <jeh@FreeBSD.org>, Thomas Hurst <tom.hurst@clara.net>, arch@FreeBSD.org Subject: Re: 64 bit counters again Message-ID: <3C4334A1.6601C5ED@mindspring.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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? 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". -- 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?3C4334A1.6601C5ED>