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.

6474 NDK Issues and questions

I am trying to understand if these NDK performance issues that I am seeing are normal. I am using NDK version 2.0

In my test case I am sending an 8 byte test packet to another application packet using tcp ip. All the code and data buffers used by the NDK are stored in external SDRAM memory. I have profiled the send command for sending this packet and the profiling results are saying that it takes approximately 50,000 cycles to send this packet. The application processor on the other side sends a confirmation packet. I profiled the recv function used to receive this packet and the profiling results state that it takes approximately 1.4 million cycles to receive a 2 byte confirmation packet. So I would like to know if putting the code and data memory in external sdram can cause this much of a performance degradation?  

In my application I will periodically have to send and receive similar sized data packets to the application processor. Currently because of the latency issues that I am seeing I am not able to meet timing. Therefore I tried to not receive the confirmation packet coming from application processor. Doing this has caused other problems during application run time. This is my application setup, I have an ISR which runs every 1 ms. During this ISR I periodically post a DSP/BIOS semaphore to a task which I use to send data to the application processor. What I have noticed when I dont receive the data packet is that  eventually the NDK blocks my transmission task with another sempahore. That is even though I am posting the correct semaphore from the ISR the transmission task will not run. This is because the transmission task is now blocked by another sempahore. The only logical conclusion that I could draw was that since there are data packets waiting in the NDK receive buffer that have not been acted upon, the NDK has blocked further transmission on that socket until this data has been received. Is this assumption correct and are there ways to get around this NDK issue? Is there an option in the NDK that I can use to ignore data received on a particular socket?

 

 

 

  • Hi, .

    I use c6671 and,

    I eventually success the use of dual port ethernet a week ago becuase John who works for TI helped me a lot.

    But, I met another problem nowadays.

    That is when I sent multicaste messages every 1ms, It becomes back out. i mean die the whole system.

    But every 100ms is OK with my borad.

    Our spec of this :

    1. get multicast messages every 1ms from linux server (40Byte)

    2. assemble the data around 126Byte and send back to linux server.

    I don't know what do I have to do now. Just I am doing changing all of variable which I think concerned with this problem.

    But as I mentioned it doesn't work.

    Please help me.

    Thanks, Ryan.

  • I make progress here a little bit.

    Actually  it's not a progress, :) just I check one thing more.

    That is just eth0 works fine but eth1 doesn't work with 1ms multicast receive but it works with 100ms muticast recevie.

    Just I think It doesn't work with accumulator when it set up in Setup_Rx in numu_eth.c.

    Anybody have any ideas? Please tell me someone who have any idea about this.

    Thanks, Ryan