Re: 2.6.12 Performance problems

[Danial Thom <danial_thom@yahoo.com>]

--- Adrian Bunk <bunk@stusta.de> wrote:

> On Fri, Aug 26, 2005 at 10:06:51AM -0700,
> Danial Thom wrote:
> >...
> > I don't think I'm obligated to answer every
> > single person who pipes into a thread. People
> who
> > say "show me your config and dmesg" are not
> > useful. Linux has long had a philisophical
> > problem of dropping packets as a "performance
> > feature", and we've already established I
> think
> > that you can't eliminate it altogether, if
> you
> > read the thread carefully.
> >...
> 
> You say you have observed for a long time a
> problem.
> 
> The only person participating in this thread
> who is one of the 
> networking maintainers is Patrick McHardy.
> 
> Did _he_ say this was a known and unfixable
> problem?

I don't know. He said that the network stack  has
absolute priority, so perhaps he can explain why
compiling a kernel causes an exponential increase
in packet loss? 

The FreeBSD "network maintainers" are largely
clueless about just about every problem in 5.x,
so I'm not sure the title qualifies someone as
knowing all there is to know. I haven't heard him
claim that he can do the things I'm doing without
any receive errors or drops. I'd like to hear
about what test he runs to test this sort of
problem.

Before you can solve a problem you have to have a
clear understanding of what the problem is, and
admit that you have a problem. 
> 
> He wanted to help you and you pissed him off
> because you refuxed to give 
> him dmesg, .config and other information that
> would have helped him to 
> debug your problem. If you don't feel obliged
> to help the persons 
> responsible for the part of the kernel you have
> a problem with to debug 
> your problem your whole initial mail was
> pointless.

I didn't refuse. I just chose to take help from
Ben, because Ben took the time to reproduce the
problem and to provide useful settings that made
sense to me. There's nothing wrong with my
machine. 

I don't know who is who; I judge people based on
the intelligence of their analysis. People
responsible for the network stack may not be the
right people, because this is more likely a
scheduler issue. There's probably nothing wrong
with the stack or the drivers; the machine just
doesn't react fast enough to avert ring overruns.

DT



		
__________________________________ 
Yahoo! Mail 
Stay connected, organized, and protected. Take the tour: 
http://tour.mail.yahoo.com/mailtour.html