This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ethernet performance <TCPIP guru question>


On Fri, Apr 26, 2002 at 11:02:21AM +0200, Roland Caßebohm wrote:

> > It sounds like a half/full duplex problem.  If the MAC is in
> > full duplex mode but the PHY is in half-duplex mode, you get
> > lots of "collisions" and dropped packets.  Try forcing the MAC
> > to half-duplex mode, which will (AFAICT) work even if the PHY
> > is in full-duplex mode.
> 
> Yes I use your driver (Thank you!!!). I think the MAC is forced to be in 
> half-duplex mode.
> 
> 	static volatile U32 MACConfigVar = 0;
> 
> in EthInit():
> 
> 	MACCON = MACConfigVar;
> 
> Because of there is no PHY-interrupt, I think the MAC couldn't change in 
> full-duplex mode after this.

I've been thinking about it, and I think my previous statement
was wrong. If the PHY is negotiating a full-duplex connection
with the other PHY, and the MAC is in half-duplex mode, that
might also cause packets to be dropped.  You should make sure
that the PHY is also being forced into half-duplex mode
(there's probably a capabilities register in the PHY, and you
can disable full duplex mode so that it will always negotiate a
half-duplex link).

> > I re-wrote IP checksum in assembly language and saw a big
> > improvement in CPU usage, and a modest improvement in
> > throughput. Holler if you want a copy to play with.
> 
> The software Ethernet CRC validation is disabled.

Good.

> But I have just seen the following in PhyReset() (lxt970.c):
> 
>     // default values for 100M encryption are wrong, so fix them
>     // and configure LEDC to be activity indicator
>      MiiStationWrite(19, LX970_ADDR, BIT7);
> 
> Maybe this is the reason for LEDC to indicate traffic?

Yes.  The 100M encryption default is set by the wiring of the
LXT970, so it may not be wrong on your board.

> So it seems to be everything right. What max. transfer rate did
> you have?

According to my notes, I got about 3M bits/second TCP echo
(data going both directions) at 10M, and about 4M bits/second
TCP echo at 100M.  Switching to assembly language checksumming
improved throughput by about 10%.

These numbers are from a custom board running a KS32C5000A
(which has to use software Ethernet CRC checking) at 33MHz. I
don't have any throughput numbers for my newer boards (S3C4510
@ 44MHz with hardware CRC).

-- 
Grant Edwards
grante@visi.com

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]