Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 11 Dec 2005 06:33:49 -0800 (PST)
From:      Danial Thom <danial_thom@yahoo.com>
To:        Kris Kennaway <kris@obsecurity.org>
Cc:        freebsd-questions@freebsd.org, Kris Kennaway <kris@obsecurity.org>
Subject:   Re: Freebsd Theme Song
Message-ID:  <20051211143349.68091.qmail@web33304.mail.mud.yahoo.com>
In-Reply-To: <20051210212424.GA80660@xor.obsecurity.org>

next in thread | previous in thread | raw e-mail | index | archive | help


--- Kris Kennaway <kris@obsecurity.org> wrote:

> On Sat, Dec 10, 2005 at 01:14:18PM -0800,
> Danial Thom wrote:
> 
> > Well thats just hogwash Kris. Pure bridging
> > performance is a measure of the efficiency of
> the
> > kernel to do rote tasks like respond to
> > interrupts, and the latencies in performing
> those
> > tasks. Its the best way, IMO, to exercise and
> > measure the efficiency of an isolated kernel.
> It
> > requires no userland activity, so your
> results
> > aren't muddled by millions of system calls.
> Its a
> > way to compare apples to apples, which is how
> > good testing is done.
> > 
> > As long as you don't have your filesystem on
> a
> > network, you're in good shape. But thats not
> even
> > the point. The point is that the purpose of
> > tearing apart 4.x was to go MP, and MP
> > performance is dismill across the board.
> 
> This statement is simply false.  It's actually
> quite funny to read.
> 
> For the readers at home: Denial is once again
> taking his narrow view
> of the world ("everything about the OS is
> accurately measured by how
> fast the kernel routes network packets!") and
> extrapolating it to
> infinity, then jumping up and down about it.

Whats "false" about it, Kris? First of all, I
didn't say that everything about the kernel can
be accurately measured by such a test, so why did
you twist it to fit your agenda? Its a "good way"
to test the interrupt and process switching
mechanisms in an isolated kernel. 

Also, since you don't see to understand the test,
bridging is not routing. Its a rote function of
moving packets from one interface to another with
very little overhead. Its purely interrupt
driven, so the kernel's latencies in processing
interrupts is well exercised. Its a good test
because, unlike crap like netperf, it doesn't
involve sockets or any userland tasks. I know
you're not a real engineer Kris, so I don't
expect you to understand, but you also aren't
qualified to discredit the test, since you don't
know a damn thing about testing.

I know you enjoy being the one-eyed man in the
land of the blind on this list Kris, But I doubt
people are stupid enough to buy into your
continued propaganda. There isn't one credible
test that shows that FreeBSD MP is worth any
consideration as a good performer, so it seems
doubtful that anyone with half a brain thinks it
is.

Everything today is networking. What good is a
fast filesystem if it sits on a klunky kernel or
slow networking system? Who's going to build a
big honking MP server if is can't handle more
network traffic than a good UP system?

Do you have a volkwagon engine in your Porche,
Kris? The problem with Kris is that he thinks
that if his car has a really cool radio that
people will buy it, even those its slow as shit.
That may be fine for the kind of guys that hang
out on the freebsd-questions list, or for little
old ladies. But its not "fine" with the kind of
people that used to rely on FreeBSD for serious
networking tasks. 

Kris is just a PR front man for a "team" of
developers that is lost. Their "theory" on how to
build a better mousetrap for MP is completely
wrong, and now they're going to try something
else, using the entire FreeBSD community as
guinea pigs. First 5.4 was the answer. Then 6.0.
Now it looks like 6.0 sucks too. Its a damn
shame.

DT

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051211143349.68091.qmail>