From: "Jim Lin" <jimmlin@solomon.com.tw>
To: "linuppc" <linuxppc-embedded@lists.linuxppc.org>,
"Georg Klug" <gklug@giga-stream.de>, <clark@esteem.com>,
<jcampos@mvista.com>
Subject: RE: Poor 8xx SCC Ethernet mode performence..
Date: Wed, 17 Jul 2002 11:39:14 +0800 [thread overview]
Message-ID: <NFBBLLKCILMGHKJGDFGHEEMGCCAA.jimmlin@solomon.com.tw> (raw)
In-Reply-To: <FFECLICFNBJAHONLGAKMKEGICFAA.gklug@giga-stream.de>
Hi :
After I change 10/100 T hub . It's speed up to 370KBps at Half duplex. 480 KBps at Full duplex in NFS envirment.
I had work follow ..
1. 10/100 HUB turn to Halt duplex because RTL 8201 not support auto-negotiaon.
I check our hardware component PHY Rtl 8201. It's not support auto-negotiation when it's wired SMI .
2.enable SCC_PMSR_FDE | SCC_PMSR_LPB , and Tested FTP Transfer again through 10/100 T HUB at Full duplex . It's about 200KBps.It's collision between HUB and RTL8201..
3.enfore FTP host nic running at 10 Full duplex mode , pulg cross line between FTP host and custom board .
It's got 470 KBps .
4. Due to custom board running in NFS envirment . It's cost some throughput.. now I trying test it without NFS envirment.
If I got more information I will post again.
Thanks and Regards
Sent: Tuesday, July 16, 2002 8:28 PM
To: Jim Lin
Subject: AW: Poor 8xx SCC Ethernet mode performence..
Hi Jim,
> I was testing SCC ethernet performance at our 850 custom board and
> found somting interesting.
>
> 1. Tested FTP Transfer about 20MB file with 10T hub I got about
> 250 k bps (someting poor ..)
Yes that is poor, indeed.
> 2. and I found the hhl20 arch/ppc/8xx_io/enet.c source code NOT
> enable full duplex ..
> and I had pmsr added SCC_PMSR_FDE | SCC_PMSR_LPB .. and
> compiling , tested FTP Transfer again.
> I got about 200 Kbps!
>
> I do not understand what is happen? Has anyone experience this?
The other performance is also poor.
First I think you should check your whole ethernet. If you really have
2 stations at a 10BaseT Hub, you definetely need half duplex traffic. It
might be that not all station are half duplex connected, so there would be
collisions and even late collisions on the network that could not be
detected. This would make the performance decrease.
Probably your hub has a collision LED This would make it easier for you to
debug the situation.
What about installing a little switch with 10/100 connectors? Then you
could use full duplex on each connector and that would boost your
performance.
Georg Klug
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
next parent reply other threads:[~2002-07-17 3:39 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <FFECLICFNBJAHONLGAKMKEGICFAA.gklug@giga-stream.de>
2002-07-17 3:39 ` Jim Lin [this message]
2002-07-17 20:11 Poor 8xx SCC Ethernet mode performence Jean-Denis Boyer
2002-07-18 1:32 ` Jim Lin
-- strict thread matches above, loose matches on Subject: below --
2002-07-16 9:37 Jim Lin
2002-07-16 17:29 ` Conn Clark
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=NFBBLLKCILMGHKJGDFGHEEMGCCAA.jimmlin@solomon.com.tw \
--to=jimmlin@solomon.com.tw \
--cc=clark@esteem.com \
--cc=gklug@giga-stream.de \
--cc=jcampos@mvista.com \
--cc=linuxppc-embedded@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).