Date: Tue, 07 Aug 2001 11:37:57 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Zach Brown <zab@zabbo.net> Cc: Mike Smith <msmith@freebsd.org>, Matt Dillon <dillon@earth.backplane.com>, freebsd-hackers@freebsd.org Subject: Re: Allocate a page at interrupt time Message-ID: <3B703585.CE87BBD3@mindspring.com> References: <200108070739.f777dmi08218@mass.dis.org> <3B6FB0AE.8D40EF5D@mindspring.com> <20010807134436.B20259@erasmus.off.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Zach Brown wrote: > > That Microsoft demonstrated that wiring down interrupts > > to a particular CPU was a good idea, and kicked both Linux' > > and FreeBSD's butt in the test at ZD Labs? > > No, Terry, this is not what was demonstrated by those tests. Will this > myth never die? Do Mike and I have to write up a nice white paper? :) That would be nice, actually. > > The environment was ridigly specified: quad cpu box, four eepro 100mb > interfaces, and a _heavy_ load of short lived connections fetching static > cached content. The test was clearly designed to stress concurrency in > the network stack, with heavy low latency interrupt load. Neither Linux > nor FreeBSD could do this well at the time. There was a service pack > issed a few months before the test that 'threaded' NT's stack.. > > It was not a mistake that the rules of the tests forbid doing the sane > thing and running on a system with a single very fast cpu, lots of mem, > and gigabit interface with an actual published interface for coalescing > interrupts. That would have performed better and been cheaper. I have soft interrupt coelescing changes for most FreeBSD drivers written by Bill Paul; the operation is trivial, and Bill has structured his drivers well for doing that sort of thing. I personally don't think the test was unfair; it seems to me to be representative of most web traffic, which averages 8k a page for most static content, according to published studies. > Thats what pisses me off about the tests to this day. The problem > people are faced with is is "how do I serve this static content > reliably and cheaply", not, "what OS should I serve my content > with, now that I've bought this ridiculous machine?". 8-) 8-). > Its sad that people consistently insist on drawing insane > conclusions from these benchmark events. I think that concurrency in the TCP stack is something that needs to be addressed; I'm glad they ran the benchmark, if only for that. Even if we both agree on the conclusions, agreeing isn't going to change people's perceptions, but beating them on their terms _will_, so it's a worthwhile pursuit. I happen to agree that their test indicated some shortcomings in the OS designs; regardless of whether we think they were carefully chosen to specifically emphasize those shortcomings, it doesn't change the fact that they are shortcomings. There's no use crying over spilt milk: the question is what can be done about it, besides trying to deny the validity of the tests. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B703585.CE87BBD3>