• State TI Thinks Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 674 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

C66 NDK is very slow when accepting the very first TCP connection (slow SYN ack)

Dmitry Gringauz53811
Intellectual 300 points

Hello,

This is a re-post from the TI-RTOS forum.  I am also submitting it here, since I believe that this issue is more relevant to C66 processor.

We are using C6655 processor, although I can see the problem on C6657 EVM board also.

I am using the following software configuration:

Code Composer 6.1

Compiler 8.0.3

BIOS 6.42.01.20

XDC Tools 3.31.02.38.core

mcsdk 2.01.02.06

pdk c6657.1.1.2.6

NDK 2.24.03.35

When the system first starts up, UDP packets on the C66 device are received correctly.  However, when I try to establish the TCP connection, I am seeing a delay of up to 40 seconds before the TI stack acknowledges the SYN request.

After this initial delay, the stack appears to be working correctly.  

The attached snapshot of the wireshark window demonstrates the problem.

Any responses and suggestions would be greatly appreciated.

Best Regards,

Dmitry.

tcp delay.zip

  • 0
    TI__Guru** 116100 points

    Dear Dmitry,

    Can you please attach the code to reproduce the problem ?

    Did you modify the NDK example and what NDK example are you using (helloworld or client) ?

    I have modified the NDK helloworld example from PDK C6657 1.1.2.6 for TCP packet transfer.

    helloWorld.c

         hHellotcp = DaemonNew( SOCK_STREAM, 0, 8, dtask_tcp_hello,
                            OS_TASKPRINORM, OS_TASKSTKNORM, 0, 3 );

    udpHello.c

    int dtask_tcp_hello( SOCKET s, UINT32 unused )
    {
        printf("TCP packet received!\n");
        return(1);
    }

    This is what I got from wireshark.


  • 0 in reply to Titusrathinaraj Stalin
    Intellectual 300 points
    Hi Titus,

    My apologies for a late response, I've been a bit tied up.

    I have followed the details of this discussion in a different thread, here:

    e2e.ti.com/.../1672952

    In short, I believe that I have found a workaround for the problem that I was seeing.

    Our system uses a full range of 32 priorities, and the default NDK task, NDK Stack Thread, was started at priority 5. Such a low priority meant that this thread was running very late during the initialization, way after the NDK was initialized. Since this task creates the NDK timer that strokes it every 100ms, my assumption is that such a late execution caused initialization hick-ups in the stack that self-cured over time.

    I found that there are two ways to resolve this issue:
    1. Up the priority of the NDK Stack Thread such that it is one of the first threads that get executed when the BIOS is started.
    2. Delay the IP address assignment until after the stack is up and running, and the system is in a stable state. In my case, I perform this address assignment from the NetworkOpen() function, which also works well for my application.

    Now, my diagnosis of the problem is just an assumption, and I would be very interested to get a more definitive explanation as to whether this assumption correct.

    Thank you for taking interest in my issue.

    Best Regards,

    Dmitry.