--- Helge Hafting <[EMAIL PROTECTED]> wrote:
> Danial Thom wrote: > > >--- Jesper Juhl <[EMAIL PROTECTED]> wrote: > > > > > > > >>On 8/21/05, Danial Thom > <[EMAIL PROTECTED]> > >>wrote: > >> > >> > >>>I just started fiddling with 2.6.12, and > >>> > >>> > >>there > >> > >> > >>>seems to be a big drop-off in performance > >>> > >>> > >>from > >> > >> > >>>2.4.x in terms of networking on a > >>> > >>> > >>uniprocessor > >> > >> > >>>system. Just bridging packets through the > >>>machine, 2.6.12 starts dropping packets at > >>>~100Kpps, whereas 2.4.x doesn't start > >>> > >>> > >>dropping > >> > >> > >>>until over 350Kpps on the same hardware > >>> > >>> > >>(2.0Ghz > >> > >> > >>>Opteron with e1000 driver). This is pitiful > >>>prformance for this hardware. I've > >>>increased the rx ring in the e1000 driver to > >>> > >>> > >>512 > >> > >> > >>>with little change (interrupt moderation is > >>> > >>> > >>set > >> > >> > >>>to 8000 Ints/second). Has "tuning" for MP > >>>destroyed UP performance altogether, or is > >>> > >>> > >>there > >> > >> > >>>some tuning parameter that could make a > >>> > >>> > >>4-fold > >> > >> > >>>difference? All debugging is off and there > >>> > >>> > >>are > >> > >> > >>>no messages on the console or in the error > >>> > >>> > >>logs. > >> > >> > >>>The kernel is the standard kernel.org > dowload > >>>config with SMP turned off and the intel > >>> > >>> > >>ethernet > >> > >> > >>>card drivers as modules without any other > >>>changes, which is exactly the config for my > >>> > >>> > >>2.4 > >> > >> > >>>kernels. > >>> > >>> > >>> > >>If you have preemtion enabled you could > disable > >>it. Low latency comes > >>at the cost of decreased throughput - can't > >>have both. Also try using > >>a HZ of 100 if you are currently using 1000, > >>that should also improve > >>throughput a little at the cost of slightly > >>higher latencies. > >> > >>I doubt that it'll do any huge difference, > but > >>if it does, then that > >>would probably be valuable info. > >> > >> > >> > >Ok, well you'll have to explain this one: > > > >"Low latency comes at the cost of decreased > >throughput - can't have both" > > > > > Configuring "preempt" gives lower latency, > because then > almost anything can be interrupted (preempted). > You can then > get very quick responses to some things, i.e. > interrupts and such. 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. DT ____________________________________________________ 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/