Hello Terry,
What Dev board/FPGA are you using?
If it is Spartan 3A DSP 1800 (possibly other similar models are affected also) there is a problem with the physical layer DCM phase shift in the gmii – currently under investigation by Xilinx (I've only experimented at gigabit speeds though).
You could try adding the following line to the implementation\system.ucf – in the GMII Receiver side DCM constraints section
"INST *gmii_rxc_dcm PHASE_SHIFT = 76"
This has yielded significant performance increases in performance at gigabit for me – but I still get some dropped frames of data.
With various tests (again at gigabit) I have found that generally the bigger the ICache and DCache the better, mainly ICache, (32K for both allows ~4.7MBytes/sec. ).
The most significant increase I have seen is by increasing the MTU to 8982 (~19.6 MBytes/sec) but this involves increasing your TEMAC fifos to 16K to handle the larger frames, and also means your infrastructure must support Jumbo frames.
Hope this helps. I would probably try the larger ICache & DCache first!
If you do find any more performance let me know – always nice to have a bit more bandwidth headroom!
Ian
From: owner-microblaze-uclinux@xxxxxxxxxxxxxx [mailto:owner-microblaze-uclinux@xxxxxxxxxxxxxx] On Behalf Of Terry ONeal
Sent: 03 November 2008 22:21
To: microblaze-uclinux@xxxxxxxxxxxxxx
Subject: [microblaze-uclinux] Ethernet performance with xps_ll_temac
Hi All, I'm working on a Microblaze system (MMU enabled) that uses xps_ll_temac, and I'm seeing poor network performance when running netperf. The phy is in 100Mb mode and I'm seeing around 2.5Mb/s with the netperf TCP_STREAM test. Microblaze caches are 16K, temac buffers are 4k, barrell shifter and HW multiplier are turned on. I'm using petalinux sources I pulled from the svn repository on 10/16/08.
What is interesting is that it appears that the kernel is losing timer ticks - if I configure netperf to run the test for 10 seconds, it actually takes 20 seconds (per my watch) to run, but the kernel only thinks it's been runnning for 10 seconds. So it appears the the ll_temac driver is hogging the CPU.
I also put togther my own application that simply creates a UDP socket and sends data through it as fast as it can - the performance is a bit better than the netperf TCP test but still way off from what I'm expecting (at least 25Mb/s).
Has anyone had better luck with xps_ll_temac performance? Any suggestions as to what may be going that is limiting the performance?
Thanks,
TerryThe information contained in this E-Mail and any subsequent
correspondence is private and is intended solely for the intended
recipient(s). The information in this communication may be
confidential and/or legally privileged. Nothing in this e-mail is
intended to conclude a contract on behalf of QinetiQ or make QinetiQ
subject to any other legally binding commitments, unless the e-mail
contains an express statement to the contrary or incorporates a formal Purchase Order.For those other than the recipient any disclosure, copying,
distribution, or any action taken or omitted to be taken in reliance
on such information is prohibited and may be unlawful.Emails and other electronic communication with QinetiQ may be
monitored and recorded for business purposes including security, audit
and archival purposes. Any response to this email indicates consent
to this.Telephone calls to QinetiQ may be monitored or recorded for quality
control, security and other business purposes.QinetiQ Limited
Registered in England & Wales: Company Number:3796233
Registered office: 85 Buckingham Gate, London SW1E 6PD, United Kingdom
Trading address: Cody Technology Park, Cody Building, Ively Road, Farnborough, Hampshire, GU14 0LX, United Kingdom
http://www.qinetiq.com/home/notices/legal.html