Re: [openrisc] Ethernet Core Performance

[Matjaz Breskvar <phoenix@opencores.org>]

* Michael@McAllisters.net (Michael@McAllisters.net) wrote:
> I have been trying to get this figured out, and still no luck.  I am 
> concerned b/c we are going to silicon next month (we just found out 
> yesterday that we are able to get in on another team's foundry run b/c 
> they aren't ready & the silicon would go to waste otherwise) and we'd 
> like to have more confidence that the problem will go away when the 
> speed improves. My gut feeling is that there is something else wrong... 
> i286 machines @ 16MHz don't take 1.5 minutes to establish a telnet 
> session, we do!  Our memories are about as fast as they can be... they 
> run at the processor's speed, but, of course, it's ~4 wishbone clocks to 
> access them (according to our hardware guy).
> 
> Is there something else I need to do?  I am, unfortunately, somewhat 
> uClinux-challenged and am wondering if there is something more I need 
> to do with the O/S? I have created a "services" file in /etc, and there is 
> an "rc" file:
> 
> ifconfig eth0 inet 132.158.113.44 netmask 255.255.0.0 hw ether 
> 00:01:02:03:04:05
> 
> route add -net 132.158.0.0 netmask 255.255.0.0 dev eth0
> 
> and that's it for the network setup.  Are there any other uClinux config 
> files?  I followed Javier Castillo Villar's email instructions (an OpenRISC 
> fourm post from Wed, Nov 27, 2202) for setting up the /dev directory.
> 
> I am at a loss for how to go about debugging this... the hardware guys 
> say that everything is hooked up correctly (they are using the Open 
> Core Ethernet MAC) and that it hooks up to our Intel PHY chip directly, 
> and they feel that it's something at my end.  I just dunno where to go.

your setup looks fine. just to be sure can you also post output
from command 'route -v', 'arp -v' and 'ifconfig'. you might want
to try seting eth0 interface without specifying its MAC address (the
driver might have a problem with it)

two other things to look into might be:

(i)  check ICMP behaviour.
     ping -ff -w 10 <target>
     ping -ff -s 640 -w 10 <target>
     ping -ff -s 64000 -w 10 <target>
     This will send out packets as fast as possible (for 10 seconds) and 
     could give you a hint where to look next.

(ii) take a look at what's going on with telnet traffic. use 'tcpdump -i eth0'
     to see all the traffic and look for resends, arp packets and any other 
     strange behaviour.

good luck,
p.
--
To unsubscribe from openrisc mailing list please visit http://www.opencores.org/mailinglists.shtml