This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Fast and reliable TCP with NDK on keystone devices

Hello,

we found several discussions how to make the TCP protocol running on Keystone devices. A lot of different patches and workarounds are published and it's difficult to assemble the common sense of all posts.

http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/271367.aspx
http://e2e.ti.com/support/embedded/tirtos/f/355/p/253488/891759.aspx
http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/p/214649/762847.aspx
http://e2e.ti.com/support/embedded/tirtos/f/355/t/253237.aspx
http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/178524.aspx
http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/p/278508/971884.aspx#971884
http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/p/243353/999492.aspx

After reading this posts there is no doubt, that TCP is not working out-of-the-box for Keystone devices and TI source-code has to be patched as well as the TI sample-code the user bases his application on.

Is there an official procedure from TI describing, how to make TCP working on Keystone devices ? Like a list of files to be patched in the C:\ti folder and in the code-samples ? Maybe with a list of the settings to be tuned (task-priorities, buffer-sizes) and where to enter this settings ?

Regards,
Roelof

  • Roelof,

    As of now there is no an official procedure to make the patches for TCP workaround. I will inform about this to development team. I hope, you have started some workaround to this as per your similar post  at: http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/361626.aspx

     

  • Thank you, we really appreciate it. You know, when on the one hand the TI marketing director for connectvity (Mr. Richard Kerslake) claims in press releases that TI finds themselves being a key player in the 'internet of things', but on the other hand the protocol for the IoT - which is TCP - is not functional over years, this doesn't fit together very well :(

    In this forum we found several patches to the TI network driver nimu.c which were created by the developer community. It turned out that after applying some of the fixes to the driver our TI evaluation boards with hardware revision 2a are now working reliably over here. But C6678 evaluation boards with hardware revision 3a are still not working. We try to find old revision 2a boards in E-Bay now. We need just a single one for our evaluation (our test setup utilizes several EVMs, we have three 2a boards and one 3a board. If we had four 2a boards we could continue our evaluation.).

    Error symptoms:

    The host is a Sitara Linux (TI board) doing a blocking socket send() with a small packet size (about 50 bytes). The blocking send() call returns and the board is waiting for a response. I assume that the data at this time has been passed to some kernel buffer (then my process continued) and Linux is sending it 'in the background'.

    At the same time the C6678 evaluation board is doing a blocking socket recvfrom(). The recvfrom operation returns sometimes fast, but sometimes it takes several seconds. When I printf("s") before the recv-command and "e" afterwards, I see something like

    seseseses

    ... pause ...

    es

    ... pause ...

    es.

    On Rev 2a boards we don't see this stalls during socket-receive, only on Rev 3a.

    Regards,
    Roelof

    (P.S.: Does anyone have a Rev2a C6678 evaluation board left, that we could buy ?)

  • Hi Roelof,

    I was posting on the first topic you linked and I got good results, my speed got to almost 900Mb/s as you can see in the topic and my board is a revision 3B. I used another board with a revision 2A and I got the same results.

    Maybe this is not a board-related problem. Are you using the same .out files on the 2A and 3A boards?

  • Hi Jose,

    thanks for answering, 900Mb/s is excellent. I use the same .out files (over TFTP) on both boards. I hope, this is ok - or do I have to use different settings ? I also use the same MAD-multicore-boot script and the same platform-configuration (mem-areas) for both boards.


    (I wonder if the 3A board possibly might be broken. Something like a bad contact on the phy/RJ45.)

    Regards,
    Roelof

  • We decided not to use Ethernet. Therefore my question has become obsolete (at least for us) and we need no further assistance.

    Thank you.

  • We still have the breadboard setup  here (four C6678 EVMs connected to one TI Sitara over an Ethernet switch) and if someday an update of nimu.c (or whatever) will be released I can verify whether it is working on our setup.

  • Roelof,

    Thanks for the update. I will check with team about the updated nimu code release and let you know the status. 

  • Roelof,

    Find the nimu.c file here, it may useful to reach your requirement.

    2627.nimu_eth.c

  • Hello Pubesh,

    we tried the patched nimu.c and it works 100%ly reliably on Rev. 2A TMDSEVM6678L boards. We have also a Rev. 3A board on which it works not reliably. This, however, could be a hardware problem on that particular piece of hardware because we allways had trouble with this piece.

    Thank you for providing this as an official solution.

    Regards,
    Roelof Berg