evmc6678 eithernet speed only 100M

Lucifar,

You will likely need to tune some parameters to get more performance with the system (I did when I was doing line rate testing with a smartbits/iperf on the MCSDK). The default out of the box values are a bit low I think. Since this is TCP with some modifications you should be able to get around the following performance. With iperf and some tweaking we were able to transmit ~920 Mbits/sec @ 1514 packets and a 4K window size. Receive was around 482 Mbits/sec with the same packet size and window size as transmit.

I am not sure what version of MCSDK you are using but you should get the latest release which is 2.04. This has some tweaks for performance for receive queue and the NIMU driver and fixes a receive bug when it runs out of buffers.

For reference look at the following diagram (I believe this is mostly correct):

The key areas to tweak are 1.) the Rx queue between the PA and NIMU driver 2.) The number of NDK buffers and 3.) possibly the Rx Socket Buffer size.

In release 2.04 the number of Rx Queue buffers was raised from 18 to around 120 something (I don't recall offhand) so with 2.04 you do not need to make this tweak yourself. 

To increase the number of NDK buffers you will need to re-build a file called pbm.c which is in the NDK directory packages/ti/src/os.  I believe there are instructions on the wiki on how to re-build NDK. You need to change this value: #define PKT_NUM_FRAMEBUF    192  The default is 192. I think I increased it by a factor of 6.

A note on the tweaks above. When the values are increased you may need to look at where you are placing the linker sections that hold that memory as you might run out of space. For example, I tested this with the out of box demo HUA (modified with a loopback) but was able to keep things in MSMC. The receive buffers that the Rx Queue and NIMU use are allocated from the OS abstracted memory handler in platform_osal.c. This by default allocates buffers from the system heap:

Program.sectMap["systemHeap"] = "DDR3";  (this is the cfg file).  Since the hello world example puts it in DDR you should be fine. Prior to 2.04 though the heap was not large enough to hold the increase in buffers so it was bumped up through this define to this value in 2.04:  heapMemParams.size = 0x300000;

You should be okay with the placement of the NDK framebuffers but as an FYI the placment of those is controlled by the following linker sections:

Program.sectMap[".far:NDK_PACKETMEM"] = {loadSegment: "L2SRAM", loadAlign: 128};

I would probably move the systemHeap to MSMC (for better performance) but you can try it in DDR first (I havent wquantified the difference in performance between MSMC and DDR3 as of yet).

Okay that's probably alot for you to digest. Let me know how it goes.

Performance is an area where wer are starting to put more focus now and hope to make further improvements. In addition we will be documenting oin the wiki with respect on how to tune the system.

Jack

Lucifar,

As Jack recommendeds, you should upgrade to the latest version of BIOS-MCSDK, which is R2.0.4 since there are some bug fixes that would affect your results.

Here is the User Guide section on product updates (via Eclipse updater within CCS or download page):
http://processors.wiki.ti.com/index.php/BIOS_MCSDK_2.0_User_Guide#Product_Updates

Raj