From: Kenneth Johansson <kenneth.johansson@inn.ericsson.se>
To: acurtis@onz.com
Cc: Ppc Developers <linuxppc-dev@lists.linuxppc.org>
Subject: Re: 8260 Network Performance update
Date: 06 Jun 2002 14:31:05 +0200 [thread overview]
Message-ID: <1023366665.24574.51.camel@groo> (raw)
In-Reply-To: <NCBBIINEHIPFGJPLBEIFOEDMDIAA.acurtis@onz.com>
I don't know if this has any relation to what you do but I have had
serious problems with nfs and 2.4.19-pre versions on X86.
Some combination of kernels have even resulted in a complete nfs failure
for the mount point.
Version 2.4.18 works and 2.4.19_pre10 works also (same version on server
and client) others have gone from lockup to 20-30 kB transfer speed when
going from nfs to nfs. One way transfers usually works ok.
I have not seen any problems with tcp traffic so it probably is
something different.
Hmm are you storing the ftp transfers in nfs ?? try mounting tmpfs and
run from that.
On Thu, 2002-06-06 at 07:00, Allen Curtis wrote:
>
> 1. Unidirectional TCP/IP traffic (ftp): get 180MBfile /dev/null
> (Thanks Jean-Denis)
>
> 10T Hub | 100BT switch
> -------------------------------------|
> 2.4.2 | 839KBps | 6526KBps |
> --------------------------------------
> 2.4.19 | 838KBps | 9412KBps |
> --------------------------------------
>
> These numbers look good!
>
> 2. Here is a description of the original test and some new test results.
>
> ------------- FTP Put -------------
> | |---------------->| |
> | Host | NFS save | 8260 PPC |
> | |<----------------| |
> ------------- -------------
>
> Given that the unidirectional transfers look good I assume that the problem
> is either resource related (running out of Ethernet buffers) or scheduling
> related. The following tests use the 2.4.19pre9 kernel but vary the number
> of RX/TX buffers. (symmetric allocation)
>
> 10T Hub | 100BT switch
> -------------------------------------|
> 16 RTB | 440KBps | 190KBps |
> --------------------------------------
> 32 RTB | 450KBps | 230KBps |
> --------------------------------------
> 64 RTB | 450KBps | 240KBps |
> --------------------------------------
>
>
> The above data shows that this is not a raw communication speed issue but
> rather a scheduling or resource issue where either FTP or NFS is getting
> starved. My guess is that FTP is taking all the receive buffers leaving
> nothing for NFS to work with when storing the file.
>
> Does this help to identify the problem and a possible solution? Additional
> tests recommendations?
>
> TIA!
>
>
>
--
Kenneth Johansson
Ericsson AB Tel: +46 8 404 71 83
Borgafjordsgatan 9 Fax: +46 8 404 72 72
164 80 Stockholm kenneth.johansson@etx.ericsson.se
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2002-06-06 12:31 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-06-06 5:00 8260 Network Performance update Allen Curtis
2002-06-06 5:41 ` Dan Malek
2002-06-06 12:41 ` Allen Curtis
2002-06-06 17:16 ` Dan Malek
2002-06-06 12:31 ` Kenneth Johansson [this message]
-- strict thread matches above, loose matches on Subject: below --
2002-06-06 4:55 Allen Curtis
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=1023366665.24574.51.camel@groo \
--to=kenneth.johansson@inn.ericsson.se \
--cc=acurtis@onz.com \
--cc=linuxppc-dev@lists.linuxppc.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;
as well as URLs for NNTP newsgroup(s).