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

Original question:

RTOS/PROCESSOR-SDK-OMAPL138: FTP - problems with transfer when change size of SO_RCVBUF and SO_SNDBUF

PROCESSOR-SDK-OMAPL138: RTOS/PROCESSOR-SDK-OMAPL138: FTP - problems with transfer when change size of SO_RCVBUF and SO_SNDBUF

Patryk_93
Intellectual 800 points
Part Number: PROCESSOR-SDK-OMAPL138
Other Parts Discussed in Thread: OMAP-L138, TEST2

Hello, 

My previous problem has not been solved:

"Is the socket blocking or non-blocking?"
The socket is in the blocking mode (default mode). When my transfer has suspended, my socket is also suspended.


"What is the value of errno when send() returns -1?"
The send() return EWOULDBLOCK - 35 error.


“when I disable cache all works fine also after increasing the size of the buffer but transfer speed is very low. Well this would indicate a cache coherency problem …!”
This is not a problem with cache coherency because when I lower transfer speed (with cache enable) all works fine. When I have disable cache the transfer is low and I think this resolved the problem.


"What is the client in this case? Is it a PC or another embdedded device. If the latter case, what is the TCP RX buffer size configured to be on the client?"
The client is a PC.

Regards,

Patryk

  • 0
    TI__Guru* 95265 points

    Hi,

    The original one was closed a month ago with suggestion:

    The need to configure such a small TX socket buffer size in the NDK indicates that the other side is slow to process the data it receives. But, TCP should handle that by informing the NDK that the window size is 0.

    If the socket is non blocking, the TX socket buffer (NDK side) may be full and “stuck” due to the exact situation mentioned above (the client’s RX buffer is full and so it has advertised a size zero window). A blocking socket would just block here, until the underlying TCP layer was able to send some data, at which point the send() request could move forward.

    But, if the socket is non-blocking, and the TX socket buffer’s full, awaiting the other side’s window to open, then send() would fail and the error code would be EWOULDBLOCK (or EAGAIN, but probably the former).

    If that’s the case then they should make the socket be blocking.

    So you have made socket in the blocking mode, the issue the same? What is the code example you used for this test? Is it from TI Processor SDK RTOS OMAP-L138?

    Regards, Eric

  • 0 in reply to lding
    TI__Guru* 95265 points

    Any update?

    Regards, Eric

  • 0 in reply to lding
    Intellectual 800 points

    Hi Eric,

    The need to configure such a small TX socket buffer size in the NDK indicates that the other side is slow to process the data it receives. But, TCP should handle that by informing the NDK that the window size is 0.

    The other site isn't slow! When a problem occured (when I can see retransmission in CCS console) the transfer freezes and when I saw on the WireShark logs I didn't see any RETRANSMISSION...

    If the socket is non blocking, the TX socket buffer (NDK side) may be full and “stuck” due to the exact situation mentioned above (the client’s RX buffer is full and so it has advertised a size zero window). A blocking socket would just block here, until the underlying TCP layer was able to send some data, at which point the send() request could move forward.

    My socket is blocking and when I see retransmission in CCS console all internet communication has been suspended. 

    So you have made socket in the blocking mode, the issue the same? What is the code example you used for this test? Is it from TI Processor SDK RTOS OMAP-L138?

    I'm using bloking mode (non-bloking sends nothing). I'm using my own code for testing.

    BTW when I disable MMU/Cache I noticed that don't have this problem (I don't have problem with memory coherency)!

    Regards,

    Patryk

  • 0 in reply to Patryk_93
    TI__Guru* 95265 points

    Patryk,

    Are you able to provide a CCS project for this for us reproduce the issue?

    Regards, Eric

  • 0 in reply to lding
    Intellectual 800 points

    Hi Eric,

    I'm working on a custom board and I don't have a time in this week. But on the next week I move a part of my program to LCDK and I will share this.

    Regards,

    Patryk

  • 0 in reply to Patryk_93
    Intellectual 800 points

    Hi Eric,

    I updated a part of my program on the LCDK board.
    I changed in the ffconfig.h #define _FS_RPATH 0 to > #define _FS_RPATH 2

    You can change ftp user name, ftp password, ip, ip mask and ip gateway in usm_emac.c in project files.

    Below are default value:
    char ftpSetUserName[] = "test";
    char ftpSetPassword[] = "test";
    char *ipAddr = "192.168.1.100";
    char *ipMask = "255.255.255.0";
    char *ipGateway = "192.168.1.254";

    Try to connect the RJ45 cable to use FTP, then try to download a larger file on the SD card and observe the program.
    Currently, SNDBUF size is set to 32768 if you want to change look at line 866 in the ftp_commands.c

    Btw

    I'm using:

    -> ti-processor-sdk-rtos-omapl138-lcdk-06.00.00.07-Windows-x86-Install.exe

    -> CCS 9.2.0.00013

    Regards,

    Patryk

    EMAC_TEST2.zip

  • 0 in reply to Patryk_93
    TI__Guru* 95265 points

    Hi,

    Thanks for sending us the CCS project. I am looking for some colleagues have OMAP-L138 EVM to reproduce and analyze the issue and will update you.

    Regards, Eric 

  • 0 in reply to lding
    Intellectual 800 points

    Any update?

    Regards, Patryk

  • 0 in reply to Patryk_93
    TI__Guru* 95265 points

    Hi,

    I don't have OMAP-L138 EVM at my site. My colleague has it but the lab is inaccessible for some reason at least for this week. We can't do the test for this. I will update you earlier next week where we are, I apologize for the unexpected delay.

    Regards, Eric

  • 0 in reply to lding
    Intellectual 800 points

    Hi Eric,

    I look forward to it.

    Regards, Patryk

  • 0 in reply to Patryk_93
    TI__Guru* 95265 points

    Hi,

    We are still waiting for the lab access. Meanwhile, we saw a reported issue on another device with TCP tx time-out: https://e2e.ti.com/support/processors/f/791/t/844091

    The solution is:

    After I did the following change in C:\ti_am3_600\ndk_3_60_00_13\packages\ti\ndk\stack\route\rtable.c:

    Change

    static uint32_t _RtNoTimer = 0;    /* Set to disable timer */

    To
    static uint32_t _RtNoTimer = 1;    /* Set to disable timer */

    and rebuilt the NDK using ndk.mak

    I am not sure if this the same cause. And if you have time to try if this helps?

    Regards, Eric

  • 0 in reply to lding
    Intellectual 800 points

    Hi Eric,

    I changed 

    static uint32_t _RtNoTimer = 0;    /* Set to disable timer */

    to 

    static uint32_t _RtNoTimer = 1;    /* Set to disable timer */

    but unfortunately it didn't solve the problem..

    Regards, Patryk

  • 0 in reply to Patryk_93
    TI__Guru* 95265 points

    Patryk,

    We are trying to duplicate the issue but had a problem to build your application with PRSDK 6.0 release.

    >> Compilation failure
    makefile:171: recipe for target 'EMAC_TEST2.out' failed

    undefined first referenced
    symbol in file
    --------- ----------------
    f_chdir ./ftp/ftp_commands.obj
    f_getcwd ./ftp/ftp_commands.obj

    error #10234-D: unresolved symbols remain
    error #10010: errors encountered during linking; "EMAC_TEST2.out" not built
    gmake[1]: *** [EMAC_TEST2.out] Error 1
    makefile:167: recipe for target 'all' failed
    gmake: *** [all] Error 2

    **** Build Finished ****

    The ti.fs.fatfs.ae9 was linked with the application. Did you change the library or in your map file where those two functions came from?

    Regards, Eric

     

  • 0 in reply to lding
    Intellectual 800 points

    Hi Eric,

    I wrote in a previous post:

    I changed in the ffconfig.h #define _FS_RPATH 0 to > #define _FS_RPATH 2

    You must change definition and rebuild FATFS library.

    Regards,

    Patryk

  • 0 in reply to Patryk_93
    Intellectual 800 points

    Any update?

    Regards, Patryk

  • 0 in reply to Patryk_93
    TI__Guru* 95265 points

    Patryk,

    I rebuilt the FS library and test application and sent to my colleague if he can reproduce.

    Regards, Eric

  • 0 in reply to lding
    TI__Guru* 95265 points

    Hi,

    We was able to setup and run your application with a static IP. We were able to ping it and FTP into it. When we test with "put <file_name>" (RX) or "get <file_name>" (TX), we found ioh->data_socket is null, and came into "550 Please use PASV instead of PORT.". How do you test with FTP to create the Tx error?

    Regards, Eric

     

  • 0 in reply to lding
    Intellectual 800 points

    Hi Eric,

    I always use FileZilla client FTP for testing and never have a problem with null data_socket.

    Please, write if that resolves the issue.

    Regards, Patryk

  • 0 in reply to Patryk_93
    TI__Mastermind 27355 points

    Hi Patryk,

    When using FileZilla, we get the following error message.

    Status: Connection established, waiting for welcome message...
    Status: Insecure server, it does not support FTP over TLS.
    Status: Server does not support non-ASCII characters.
    Status: Logged in
    Status: Retrieving directory listing...
    Command: PWD
    Response: 550 Failed to get pwd.
    Error: Failed to retrieve directory listing

    Have you come across this before?

    Regards,
    Sahin

  • 0 in reply to Sahin Okur
    Intellectual 800 points

    Hi Sahin,

    I don't have access to LCDK today and check it tomorrow, but you can be sure that the SD card inserted? Is the SD card format is FAT? Maybe check with different card?

    Response: 550 Failed to get pwd. -> occurs when f_getcwd returns other value than FR_OK

    PS: I checked and the problem occurs when the SD card is not inserted.

    Regards, Patryk

  • 0 in reply to Patryk_93
    TI__Mastermind 27355 points

    Hi Patryk,

    My mistake, the SD card wasn't inserted. 

    I was able to transfer 1-1.5GB sized files individually at ~3.7MB/s. With parallel transfers, I could only do two at a time. The third transfer would immediately fail. Please see screenshots below. 

    This was on the LCDK. 

    Regards,
    Sahin

  • 0 in reply to Sahin Okur
    Intellectual 800 points

    Hi Sahin,

    Don't worry, my FTP program is in development but the problem is elsewhere. Do you check what happens when you increase SO_SNDBUF and tries download file from SD card?

    Don't you have problem with suspended SD card?

    Regards, Patryk

  • 0 in reply to Patryk_93
    Intellectual 800 points

    Any update?

    Regards, Patryk

  • 0 in reply to Patryk_93
    TI__Mastermind 27355 points

    Sorry for the delay. I tested this today, I increased SO_SNDBUF to 0x8000 and SO_RCVBUF to 0x8001 and observed the following timeout errors when trying to download from the SD card - still debugging.

    TcpTimeoutRexmt: Retransmit Timeout
TcpTimeoutRexmt: Retransmit Timeout
TcpTimeoutRexmt: Retransmit Timeout
TcpTimeoutRexmt: Retransmit Timeout
TcpTimeoutRexmt: Retransmit Timeout
TcpTimeoutRexmt: Retransmit Timeout
TcpTimeoutRexmt: Retransmit Timeout
TcpTimeoutRexmt: Retransmit Timeout

    Is this the same issue you were seeing?

  • 0 in reply to Sahin Okur
    Intellectual 800 points

    Hi Sahin,

    Yes, It's the same issue.

    Regards, Patryk

  • 0 in reply to Patryk_93
    Intellectual 800 points

    Any update?

    Regards, Patryk

  • 0 in reply to Sahin Okur
    Intellectual 800 points

    Hello, anyone can help me? This is very important for me. Can you have any advice for me?