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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
