CC3200 TCP_NODELAY Small Packet Handling

Hi Justin,

We will check and get back.

Regards,
Ankur

Hi Ankur,

Thank you for the response.

Do you have recommendations for supporting small packet sizes? I read in a CC3000 thread that you recommend padding the packet to 1400 bytes. This requires that I add support for this in my packet parser on the receiving end which was not previously part of the implementation. Is there some way to flush a send?

I also noticed that if I break the small packet into two calls to sl_send, it will send the small packet. For example, I have a 100 byte packet, I call sl_send with the first byte, then call sl_send with the remaining 99 bytes, the packet is sent. Is this by design?

Thanks,
-justin

Hi,

I'm also using a TCP/IP based command/response protocol which mostly sends very small 'packets'.

After each command, the client(PC) waits for a response from the server(MSP5438A + CC3100), before issueing the next command.

We are seeing pretty bad throughput, in order of 60 - 70kilobytes/s.

The SPI bus to the CC3100 is 12.5MHz, MCU runs at 25MHz.

Can anyone please advice on how we could up the performance?

Hello Bart,

First, you are "riding" on a thread that has been closed for a long time.

The good practice is to open a new thread and link to this one as a reference.

Can you please do that?

Regarding your question, it really depends on the followings:

• how frequent are you calling to recv/send APIs?
• what is the size of the packet? the smaller the packet is, the more overhead you would get (WiFi/IP/TCP headers)
• are you sure the MCU is not busy with other stuff such that recv/send may inherently be delayed?
• how is the air environment? congested? other protocols running in parallel like 2.4GHz bluetooth, others?

Regards,

Shlomi

Hello,

Any update on the post?

Regards,
Shlomi

I was using a self made command/response protocol where the client sends a command to the server ( eg: write this block of data to position x ), then the client waits for an ACK from the server before issuing the next command.

I was using packets of approx 520 bytes in the send command, then waiting for an ACK packet of approx 6 bytes.

I found that the biggest bottleneck was the RTT (round trip time). It took approx 3-4 ms for a command to be sent and an ACK to be received without extra processing. This delay between each block of 512 bytes (+header overhead) caused fairly slow comms. Approx 60kb/s could be achieved.

I changed the protocol to allow much larger blocks to be sent before waiting for an ACK. 64kb in stead of 520bytes. This increased performance to about 230kb/s.

I think the biggest bottleneck now is the FS where the data is eventually going to/coming from.

Thanks for the update, Shlomi.