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,
Terry
The 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
|