• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 98 subscribers
  • Views 1764 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.

NDK Http Server server is very slow at sending large data

Paul Scullin
Prodigy 120 points

Other Parts Discussed in Thread: AM3357, SYSBIOS

We're having a problem with our implementation of the the NDK HTTP server. It seems that when transferring data that requires more than a single packet for payload a 2 to 3 second delay between packets is observed. When either a static file or CGI data fits in a single packet, page updates are below 30ms and page refreshes are well below 1s.

Build uses

Custom AM3357 platform based on ICE V2 (same network phys, via icss only)

am335x_sysbios_ind_sdk_1.1.0.8

NDK 2.24.1.18

SYS/BIOS 6.41.4.54

System Analyser 2.0.2.39

I'm guessing that there should be a semaphore to signal that the hardware (or lower stack level) is ready for the next packet but this does not seem to be working and the 2-3 seconds is some sort of time-out period. 

1. Is this a fundamental NDK issue ?

2. Is there any SYS/BIOS or NDK configuration parameter we may have changed that can cause this problem ?

Any guidance in solving this problem would be appreciated.

  • 0
    TI__Guru**** 393215 points
    The ISDK team has been notified. They will respond here.
  • 0 in reply to Biser Gatchev-XID
    TI__Expert 7570 points

    Hi Paul

    A couple of questions to get started.
    Is this based upon the enetLwip_sysbios example using the CPSW Ethernet ? If so have you also checked the lwIP faq.
    What packet size are you using ?
    How many packets will trigger the delay?
    Can you capture a wireshark log of this error?

    David

  • 0 in reply to David Zaucha
    Prodigy 120 points

    Hi David,

    Thanks for the response.

    We're not using LWIP or CPSW.

    I had been using the debugger in the chrome for my timing, WireShark definitely gives much more insight.

    I noticed response and packet exchange is quick, but the problem is being caused by skipped data or missing packets. Once the device sees 3 duplicate ACK sequence numbers it stalls for 2s then sends the missing data.

    The data being transferred was about 50k and it stalled a number of times taking 8.2s to complete transfer.

    Filters for Device

    eth.addr == 54:4a:16:b5:2c:db

    ip.addr == 192.168.10.218

    366 (20.45s)  My HTTP request for data

    370 (20.46) TCP Ack from device (412)

    373 (20.49) Contents of httpSendStatusLine() from device (104 bytes | 50)

    374 (20.49) Contents of httpSendEntityLength() from device (79 bytes | 25)  [Tells us http content length = 49716]

    375 (20.49) Contents of httpSendEntityLength() from device (1514 bytes | 1460)

    376 (20.49) TCP Ack from PC (1536)

    377 (20.49) Continued [1536] from device  (1514 bytes | 1460)

    378 (20.49) Continued [7376] from device (871 bytes | 817)   ****** Big Gap in SEQ***** ( Seems to have missed 3 full pkts)

    379 (20.49) Continued [8193] from device (1514 bytes | 1460)  

    380 (20.49) Continued [9653] from device (129 bytes | 75)  

    381 (20.49) TCP Ack from PC (2996)

    382 (20.49) TCP Ack from PC (2996)

    383 (20.49) TCP Ack from PC (2996)

    384 (20.49) Continued [9728] from device (1514 bytes | 1460)  

    385 (20.49) TCP Ack from PC (2996)

    421 (22.45) Continued [2996] from device (1514 bytes | 1460)   ****** Now sending missing data ******

    422 (22.50) TCP Ack from PC (4456)

    423 (22.50) Continued [4456] from device (1514 bytes | 1460)

    424 (22.50) Continued [5916] from device (1514 bytes | 1460)

    425 (22.50) TCP Ack from PC (11188)

    426 (22.50) Continued [11188] from device (1514 bytes | 1460)

    427 (22.50) Continued [12648] from device (1514 bytes | 1460)

    428 (22.50) Continued [14108] from device (1514 bytes | 1460)

    429 (22.50) TCP Ack from PC (15568)

    430 (22.50) Continued [15568] from device (1514 bytes | 1460)

    431 (22.50) Continued [17028] from device (1514 bytes | 1460)

    432 (22.50) Continued [19380] from device (1514 bytes | 1460)  ****** Gap in SEQ missing 892 bytes

    433 (22.50) TCP Ack from PC (18488)

    434 (22.50) Continued [20840] from device (1514 bytes | 1460)

    435 (22.50) Continued [2230] from device (1514 bytes | 1460)

    436 (22.50) TCP Ack from PC (18488)

    437 (22.50) TCP Ack from PC (18488)

    461 (24.46) Continued [18488] from device (1514 bytes | 1460)  ****** Sending missing data ******

    462 (24.51) TCP Ack from PC (23760)

    Log file attached...

    NDK_Delay.zip

  • 0 in reply to Paul Scullin
    TI__Expert 7570 points

    Hi Paul

    Thank you.  Could you give me an overview of your software architecture? Did you derive the network implementation from one of our examples?

    This would help give us some direction on what issues and options to investigate.

    Since your are not using LWIP - the software version you are using is a older version of a software branch that is supported only for legacy customers and products.  If this is a legacy product, then we recommend moving to the latest SYSBIOSSDK-IND-AM335X: SYSBIOS Industrial SDK for AM335x Processors v01.01.02.01 version .  http://software-dl.ti.com/sitara_indus/esd/AM335x_SYSBIOS_Industrial_SDK/latest/index_FDS.html

    If this is a new product development then we would recommend moving to the current active development branch SYSBIOSSDK-IND-SITARA:  SYSBIOS Industrial Software Development Kit (SDK) for AM335x and AM437x v02.01.02.02  http://downloads.ti.com/sitara_indus/esd/SYSBIOSSDK-IND-SITARA/latest/index_FDS.html

    David

  • 0 in reply to David Zaucha
    Prodigy 120 points

    We have an existing product using the same platform using the the 1.1.0.8 SDK, which is why we stuck with it for this development.

    We will definitely take on your suggestion to update the SDK, but its a significant change and just to risky at the moment for our deadline.

    I've improve the delay dramatically by replacing the httpSendClientStr, to break up the send into packet sizes and allowing a 1ms delay between sends. Not the most elegant, but getting the transfer down to 35ms is good enough for now.

    Note, without the 1ms delay the problem still occurs even with the send broken up.

     //httpSendClientStr(s, pTempBuf);

     while (pos < data_size)

     {

      int bytes_to_send = data_size-pos;

      if(bytes_to_send > 1460) bytes_to_send = 1460;

      send(s, pTempBuf+pos,bytes_to_send , 0);

      pos+=bytes_to_send;

      Task_sleep(1);

      }

  • 0 in reply to Paul Scullin
    TI__Expert 7570 points

    Paul

    Thank you for the update.

    David