[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [microblaze-uclinux] Ethernet performance with xps_ll_temac



Hi all,

I did some tests some days ago before starting your discussion.
I made a page with some results for ml505 board with ll_temac. There are some
options. On the base of your discussion I can tell that MMU kernel is a little
bit slower than noMMU but difference is not big.
You can look at it (http://monstr.eu/wiki/doku.php?id=kernel:testing:net).

There is testing script too. Thanks for sending your results. Then we can look
where your problem is.

If anyone send my results for any devel board, hw configuration, etc. , I'll add
it there. Just send output from script and some information about your hw
configuration.

Cheers,
Michal



Terry ONeal wrote:
> I tried again on the spartan3E1600 board  with the MMU enabled -
> performance was just as bad..  I then took the original S3A3400 board
> system, disabled the MMU, rebuilt the kernel, and got about a 10x
> improvement:
> 
> #netperf -H 192.168.0.1 <http://192.168.0.1>
> TCP STREAM TEST from 0.0.0.0 <http://0.0.0.0> (0.0.0.0 <http://0.0.0.0>)
> port 0 AF_INET to 192.168.0.1 <http://192.168.0.1> (192.168.0.1
> <http://192.168.0.1>) port 0 AF_INET
> Recv   Send    Send                         
> Socket Socket  Message  Elapsed             
> Size   Size    Size     Time     Throughput 
> bytes  bytes   bytes    secs.    10^6bits/sec 
> 
>      0  16384  16384    10.00      18.81  
> 
> 
> 
> So it appears to me that this is related to the MMU being enabled - or
> the way the ll_temac driver is written..
> 
> Terry
> 
> 
> 
> On Tue, Nov 4, 2008 at 10:48 AM, Terry ONeal <terryoneal3@xxxxxxxxx
> <mailto:terryoneal3@xxxxxxxxx>> wrote:
> 
>     I'm using the Spartan3A DSP 3400 board.. That is a good point, this
>     could be a physical layer issue, I've seen/heard of the same thing
>     in the past... I'm going to give a couple of the other reference
>     designs a try and see if other boards give better results..
> 
>     Thanks,
>     Terry
> 
> 
> 
>     On Tue, Nov 4, 2008 at 4:14 AM, Whitmore Ian J
>     <IJWHITMORE@xxxxxxxxxxx <mailto:IJWHITMORE@xxxxxxxxxxx>> wrote:
> 
>         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>
>         [mailto:owner-microblaze-uclinux@xxxxxxxxxxxxxx
>         <mailto:owner-microblaze-uclinux@xxxxxxxxxxxxxx>] *On Behalf Of
>         *Terry ONeal
>         *Sent:* 03 November 2008 22:21
>         *To:* microblaze-uclinux@xxxxxxxxxxxxxx
>         <mailto: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
>         <http://www.QinetiQ.com/home/legal.html>
> 
> 
> 
___________________________
microblaze-uclinux mailing list
microblaze-uclinux@xxxxxxxxxxxxxx
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/