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

Christopher Weber

Part Number: CC3120BOOST

Tool/software: Code Composer Studio

Hello,

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;
    ptr++;
}  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?

over 4 years ago

0 Michael Reymond over 4 years ago

TI__Mastermind 40965 points

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?

Regards,

Michael

0 Christopher Weber over 4 years ago in reply to Michael Reymond

Genius 4995 points

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.

0 Michael Reymond over 4 years ago in reply to Christopher Weber

TI__Mastermind 40965 points

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.

Regards,
Michael

0 Christopher Weber over 4 years ago in reply to Michael Reymond

Genius 4995 points

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.

Wi-Fi

Wi-Fi forum

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