Re: 2.6.12 Performance problems

• Previous message: Jeff Garzik: "Re: Another libata TODO item"
• In reply to: Jesper Juhl: "Re: 2.6.12 Performance problems"
• Next in thread: Ben Greear: "Re: 2.6.12 Performance problems"
• Reply: Ben Greear: "Re: 2.6.12 Performance problems"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date:	Wed, 24 Aug 2005 10:26:31 -0700 (PDT)
To: Jesper Juhl <jesper.juhl@gmail.com>

--- Jesper Juhl <jesper.juhl@gmail.com> wrote:

> On 8/24/05, Danial Thom <danial_thom@yahoo.com>
> wrote:
> > --- Patrick McHardy <kaber@trash.net> wrote:
> >
> > > Danial Thom wrote:
> > > > I think part of the problem is the
> continued
> > > > misuse of the word "latency". Latency, in
> > > > language terms, means "unexplained
> delay".
> > > Its
> > > > wrong here because for one, its
> explainable.
> > > But
> > > > it also depends on your perspective. The
> > > > "latency" is increased for kernel tasks,
> > > while it
> > > > may be reduced for something that is
> getting
> > > the
> > > > benefit of preempting the kernel. So you
> > > really
> > > > can't say "the price of reduced latency
> is
> > > lower
> > > > throughput", because thats simply
> backwards.
> > > > You've increased the kernel tasks latency
> by
> > > > allowing it to be pre-empted. Reduced
> latency
> > > > implies higher efficiency. All you've
> done
> > > here
> > > > is shift the latency from one task to
> > > another, so
> > > > there is no reduction overall, in fact
> there
> > > is
> > > > probably a marginal increase due to the
> > > overhead
> > > > of pre-emption vs doing nothing.
> > >
> > > If instead of complaining you would provide
> the
> > > information
> > > I've asked for two days ago someone might
> > > actually be able
> > > to help you.
> >
> > Because gaining an understanding of how the
> > settings work is better than having 30 guys
> > telling me to tune something that is only
> going
> > to make a marginal difference. I didn't ask
> you
> > to tell me what was wrong with my setup, only
> > whether its expected that 2.6 would be less
> > useful in a UP setup than 2.4, which I think
> > you've answered.
> >
>
> I hope you're implying that the answer is; no,
> it's not expected that
> 2.6 is less useful in a UP setup than 2.4 :-)

I think the concensus is that 2.6 has made trade
offs that lower raw throughput, which is what a
networking device needs. So as a router or
network appliance, 2.6 seems less suitable. A raw
bridging test on a 2.0Ghz operton system:

FreeBSD 4.9: Drops no packets at 900K pps
Linux 2.4.24: Starts dropping packets at 350K pps
Linux 2.6.12: Starts dropping packets at 100K pps

Now the 2.6.12 keyboard is always nice and
snappy, but thats not what I need. I can't have a
box drop traffic if some admin decides to
recompile some application. Linux is fine on
low-medium speed networks, but at a certain
capacity, depending on the specs of the machine
of course, linux drops packets.

If I do a "make install" in BSD when on a busy
network, it takes a long time, but it doesn't
drop packets. Linux compiles a lot faster, but it
drops buckets of packets. Its just not the
priority thats needed for a networking device.

Danial

                
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

• Previous message: Jeff Garzik: "Re: Another libata TODO item"
• In reply to: Jesper Juhl: "Re: 2.6.12 Performance problems"
• Next in thread: Ben Greear: "Re: 2.6.12 Performance problems"
• Reply: Ben Greear: "Re: 2.6.12 Performance problems"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]