Re: Debugging Network Performance

3 messages, 2 authors, 2002-06-05 · open the first message on its own page

Re: Debugging Network Performance

From: Bill Fink <hidden>
Date: 2002-06-05 05:18:32

On Tue, 4 Jun 2002, Allen Curtis wrote:
quoted
If you think it is a kernel problem some benchmarks may help you narrow
down the problem. Networks are pretty fluid and sometimes hard to get
reproducible results. When I try to determine driver/kernel network
perfomance I try to use an isolated network where I have control over all
traffic or I use test hardware such as IXIA or Smartbits.
All testing is done on an isolated network. I do not believe that the
problem is in the driver itself. The driver has not changed significantly. I
do need to check the error path since it appears that errors actually help
performance.

What is the best way to track packet processing through the kernel?
When I was helping to investigate a performance problem with the SUNGEM
driver versus the GMAC driver, Anton Blanchard made the following suggestion:

    "It would be interesting to see where the cpu is being used. Could you
    boot with profile=2 and use readprofile to find the worst cpu hogs
    during a run?"

I actually never tried doing this as the problem was resolved through
other methods, but it sounded like something possibly useful to try.

The problem with the poor SUNGEM performance turned out to be lots of
extraneous unnecessary interrupts, so you might want to check out the
eth0 interrupts in /proc/interrupts, comparing the two cases.

						-Bill

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

RE: Debugging Network Performance

From: Allen Curtis <hidden>
Date: 2002-06-05 13:16:18

    "It would be interesting to see where the cpu is being used. Could you
    boot with profile=2 and use readprofile to find the worst cpu hogs
    during a run?"
Where can I find documentation on the profile=## option? Are there also
tools that will help to interpret the logs?
The problem with the poor SUNGEM performance turned out to be lots of
extraneous unnecessary interrupts, so you might want to check out the
eth0 interrupts in /proc/interrupts, comparing the two cases.
I will check the interrupts. There are several errata regarding the FCC
interface. I know that the code considered these cases but I need to make
sure that it did not get removed mistakenly.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Debugging Network Performance

From: Bill Fink <hidden>
Date: 2002-06-05 13:56:31

On Wed, 5 Jun 2002, "Allen Curtis" wrote:
quoted
    "It would be interesting to see where the cpu is being used. Could you
    boot with profile=2 and use readprofile to find the worst cpu hogs
    during a run?"
Where can I find documentation on the profile=## option? Are there also
tools that will help to interpret the logs?
Since I didn't actually try it, I don't have a lot more information.
From /usr/src/linux/Documentation/kernel-parameters.txt:
        profile=        [KNL] enable kernel profiling via /proc/profile
                        (param:log level).

And of course check the readprofile man page.

						-Bill

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help