• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 698 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.

AM3352: NDK small TCP packet size

Markus A
Intellectual 435 points
Part Number: AM3352


Hello,

I use the NDK (v2.26.0.08 because of compatibility reasons) to implement a TCP/IP server on a AM3352.
The server works quite well so far, but when I send data, the TCP/IP stack only transmits 1 databyte per TCP packet.

We use a higher level protocol over this TCP/IP connection which is able to move only 1 byte per statemachine call into the send buffer.
So I use the NDK "send" function to move 1 byte into the TCP/IP buffer.
This happens as long as the whole "protocol packet" has been sent (done in a while loop, so practically multiple "send" calls in a row).

I have *not* enabled the "TCP_NODELAY" mechanism.
To be sure I also have tried to actively disable the "TCP_NODELAY" mechanism but without any success.

int32_t opt = 0;
if (setsockopt(tcpip->clientSocket, IPPROTO_TCP, TCP_NODELAY, &opt, sizeof(opt)) == SOCKET_ERROR) {
    UART_printf("*** Disable NODELAY error\n");
} else {
    UART_printf("Disable NODELAY OK\n");
}

AFAIK the Nagle algorithm (=TCP_NODELAY disabled) should prevent such behaviour, isn't it?

Below a screenshot of WireShark capturing the AM3352 response 1-databyte packets:

192.168.1.10 -> PC
192.168.1.20 -> AM3352

NDK buffer configurations:

NDK TCP settings:

Thank you,
Markus

  • 0
    TI__Guru 56085 points

    Hi Markus

    It sounds like the TCP/IP server setup issue. Have you tried the NIMU_FtpExample_bbbAM335x_armExampleproject in the same Processor SDK RTOS?

    Does it shows the same small packet size issue? If yes, please let us know the Processor SDK RTOS version. We will do further investigation. If not, you may want look into your TCP/IP server setup. like maximum packet size etc.

    Ming

  • 0 in reply to Ming Wei
    Intellectual 435 points

    Hello Ming,

    maybe it is not a setup issue because if I implement a software buffer between your stack and my application (e.g. with 512 bytes) and send the whole buffer content at once instead of 1 byte each, I got bigger packets.

    I do nothing special at my setup:
    * socket (AF_INET, SOCK_STREAM, IPPROTO_TCP)
    * bind (IPv4)
    * listen (max conn = 1)
    * set timeout for listener socket by function "setsockopt" (3s)
    * accept
    * send/receive

    Used toolchain:
    * PDK 1.0.15
    * NDK 3.60.0.13
    * SYS BIOS 6.75.2.00
    * XDCtools 3.50.8.24

    I may try the FTP server demo but this demo actively enables the "TCP_NODELAY" flag.
    AFAIK this forces the packet size to go down in exchange for faster response for each FTP command.
    This demo also does not send 1 Byte but a whole string (=multiple bytes) per "send" call.

    Kind regards,
    Markus

  • 0 in reply to Markus A
    TI__Guru 56085 points

    Hi Markus,

    You mentioned in the response in https://e2e.ti.com/support/processors/f/791/t/844091#pi320966=2 that the fix not only fixed the HTTP server issue, but also the TCP/IP server issue. Do you mean this problem is fix with the same change? If so, please mark this thread "Resolved" Thanks!

    Ming

  • 0 in reply to Ming Wei
    Intellectual 435 points

    Hello Ming,

    no, this response only solves the "stack crash" issue of the HTTP Server and TCP/IP stack.

    I still have to use a custom software buffer (currently I use a 512 byte buffer) between my application and your stack to get bigger packet sizes.

    So, my current work around is:
    * Instead of sending each byte, I transfer every byte to my buffer
    * when the buffer is full or the frame is complete, I flush (send) the current buffer content at once

    But IMHO this is not an ideal solution, because I also allocated big TCP/IP buffers (via TI RTOS cfg file) which might not be used or needed.

    Kind regards,
    Markus

  • 0 in reply to Markus A
    TI__Guru 56085 points

    Hi Markus,

    Let me re-phrase your question:

    You said in your first post that the one byte TCP/IP packet was caused by your higher level protocol which can only move 1-byte at a time. In order to work around the issue, you used your own buffer for TCP/IP transfer. Essentially you accumulating the 1-bytes transfers into a bigger packet using your own buffer, then you transfer the cumulated frame to TCP/IP when you think the frame is completed. This work around is working properly.

    The issue here is that you do not want to allocate your own buffer or you do not want to allocate unnecessary TCP/IP buffers.

    If what I re-phrased above is correct, then

    1. first I do not see a way you can get rid of your own buffer, because the limitation from the higher level protocol.

    2. secondly, you can try to adjust the following parameters in *.cfg files

    Tcp.transmitBufSize = 16384;
    Tcp.receiveBufSize = 65536;
    Tcp.receiveBufLimit = 65536;

    to reduce the overall memory buffer size.

    Ming