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.

CCS/CC3120BOOST: Slow performance on "accept -recv"

Part Number: CC3120BOOST

Tool/software: Code Composer Studio


I have ported the Simple Link driver to the am335x line, and have things working as expected.

I am seeing a very slow performance when I create my own server.  Specifically, the first read is taking about 250ms to obtain about 500 bytes after the connection is accepted.

The server is using regular blocking calls for sl_Create, sl_Bind, sl_Listen, sl_Accept, and sl_Read.  The basic code design is:

char *ptr = buffer;
do {
    recv(m_socket, ptr, 1 ... )   /* one byte at a time */
    if (*ptr == DELIMITER) break;
}  while ((ptr - buffer) < MAX_BUFFER);
/*  Digest the block to determine payload and then...  */
recv(m_socket, payload, payload_size,... );

After bringing up the server, and the accept call returns, the full read completes about 250ms later.

(A competitors device uses the interrupt to signal when to perform a "recv", and can read the same block of data in 1/10 the time. )

This device seems to send the request to the device via SPI, block until it gets an interrupt, then reads the amount of data requested.  Is this a correct assessment?  What are any recommended ways to improve the performance?

  • Hi Chris,

    The general procedure of having a sl_Recv() sending a SPI request, blocking waiting for an interrupt if the socket is nonblocking, and then sending another SPI request to read back the data received is correct.

    On the RTOS platforms we support such as TIRTOS and FreeRTOS, these SPI transactions happen quickly and do not impede the operation of the program, but perhaps on the AM335x the SPI drivers take longer to perform transfers.

    To clarify, is the 250ms including the time it takes to go from sl_Accept() returning to the first 500 byte packet being read? Or is it the time it takes once your code has reached that receive loop, so just the amount of time it takes to go from the start of the first receive until all 500 bytes are read?



  • Michael,

    Specifically, the code (which works with the NDK and Ethernet interface) is to "recv" bytes one at a time looking for the delimiter. This works well because the packet buffers are in memory, and DMA accessed.

    In this case, the request for a single byte is generating a round trip:  SPI - INT - SPI.  I have confirmed that is where the delay is coming from.

    Up to 1/3 of a second to read a couple hundred bytes one at a time.

    Once the delimiter is found, the packet is parsed.  Then the size of the payload can be requested.  The payload of a several byte to several thousand bytes is read with a single SPI request.  That second read is actually faster than the accumulated collection of single byte reads.

    The solution, will be to move a larger request and break the data internally, moving the portion after the delimiter is located (which is not predictable) to the payload buffer.

  • Hi Chris,

    Thanks for reporting back the source of your delay. Indeed, the round trip time for a one byte receive can take significant amounts of time.

    Let me know if you run into any more delay issues or have further questions using the host driver.


  • Michael,

    Thanks. This topic is closed as understood.  And I am now developing to use bypass mode and inject the packets directly into the TI NDK we have running in the target device.  I already did it with USB/RNDIS a few years ago, should be straight forward.

    The battle now, which I am again struggling with inadequate doc, is connecting to an enterprise managed WiFi network using 802.1X and a RADIX server.  Those posts are on another thread in the forum.