mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Danial Thom <danial_thom@yahoo.com>
To: Jesper Juhl <jesper.juhl@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2.6.12 Performance problems
Date: Wed, 24 Aug 2005 10:26:31 -0700 (PDT)	[thread overview]
Message-ID: <20050824172631.11829.qmail@web33309.mail.mud.yahoo.com> (raw)
In-Reply-To: <9a87484905082409356c549512@mail.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 
 

  reply	other threads:[~2005-08-24 17:26 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-21 16:57 Danial Thom
2005-08-23  7:12 ` Helge Hafting
2005-08-23 17:10   ` Danial Thom
2005-08-23 17:21     ` Patrick McHardy
2005-08-24 16:24       ` Danial Thom
2005-08-24 16:35         ` Jesper Juhl
2005-08-24 17:26           ` Danial Thom [this message]
2005-08-25  4:51             ` Ben Greear
2005-08-25  6:08               ` Danial Thom
2005-08-25  6:15                 ` Ben Greear
2005-08-26  3:29                   ` Danial Thom
2005-08-26 22:18                     ` Danial Thom
2005-08-25  6:34                 ` Ben Greear
2005-08-25 14:26                   ` Danial Thom
2005-08-25 16:55                     ` Ben Greear
2005-08-25 20:45                       ` Danial Thom
2005-08-26 19:10                       ` Benjamin LaHaise
2005-08-27 11:19                 ` Vladimir B. Savkin
2005-08-27 14:35                   ` Danial Thom
2005-08-23 18:02     ` Sven-Thorsten Dietrich
2005-08-23 20:10       ` Danial Thom
2005-08-23 20:22         ` Sven-Thorsten Dietrich
2005-08-24 16:33           ` Danial Thom
2005-08-23 20:40         ` Patrick McHardy
2005-08-23 23:29           ` Ben Greear
2005-08-24 16:39           ` Danial Thom
2005-08-23 21:32     ` Jesper Juhl
2005-08-24 17:03       ` Danial Thom
     [not found] <2230.192.167.206.189.1124721719.squirrel@new.host.name>
2005-08-22 15:41 ` Danial Thom
2005-08-26 13:17   ` Adrian Bunk
2005-08-26 15:34     ` Danial Thom
2005-08-26 16:21       ` Adrian Bunk
2005-08-26 17:06         ` Danial Thom
2005-08-26 18:30           ` Adrian Bunk
2005-08-26 21:09             ` Danial Thom
2005-08-26 23:27               ` Ben Greear
2005-08-27 14:44                 ` Danial Thom
     [not found] <9a87484905082111205d27c1aa@mail.gmail.com>
2005-08-21 20:21 ` Danial Thom
2005-08-21 21:21   ` Jesper Juhl
2005-08-22 11:46   ` Denis Vlasenko
  -- strict thread matches above, loose matches on Subject: below --
2005-08-21 17:07 Danial Thom
2005-08-21 15:46 Danial Thom
2005-08-21 16:15 ` Patrick McHardy
2005-08-21 16:18   ` Danial Thom
2005-08-21 16:36     ` Patrick McHardy
2005-08-21 19:47 ` Andrew Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050824172631.11829.qmail@web33309.mail.mud.yahoo.com \
    --to=danial_thom@yahoo.com \
    --cc=jesper.juhl@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®