• Locked Locked
  • Replies 10 replies
  • Subscribers 100 subscribers
  • Views 2166 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 Retransmit of packet

David Crose
Intellectual 475 points

I am looking for a description of how/when a packet is retransmitted; the NDK documents I have seen are not detailed enough. I have a situation where every once-in-awhile a packet is not seen by the PC, which results in a series of duplicate ACKs (12 or so as seen in Wireshark) followed by a retransmission of the packet (and a 50 ms delay here). This causes a backup for me, as we need to transmit a packet every 5 ms or so, and I end up missing some data going out. I'm not sure why it takes so long to retransmit. I have tried increasing my packets from 48 to 70 w/o luck. I am only now as we speak trying to run the periodic timer at 25ms to see if that helps. 

  • TI__Mastermind 32475 points

    What version of BIOS and NDK are you using and what device are you on?

  • in reply to judahvang
    Intellectual 475 points

    Device = 320C6727 DSP

    BIOS = 5.20

    NDK = 1.8   I believe (docs are circa Aug-2005)

     

  • TI__Mastermind 45025 points

    David,

    Can you please attach the Wireshark capture that shows the problem?  Please also explain which IP address is for the PC and which is for the 6727.

    The NDK 1.8 is very old.  It could be that you are seeing a problem that has been fixed in more recent versions.

    Steve

  • in reply to Steven Connell
    Intellectual 475 points

    Line 67200 is where the first duplicate ACK is. Retransmission is at 67221.

    48362 is the 6727; cisco-sccp is the PC.

    Thanks.

     

  • in reply to David Crose
    TI__Mastermind 45025 points

    Hi David,

    I didn't see the attachment.  Could you try again please?

    Steve

  • in reply to David Crose
    TI__Mastermind 45025 points

    Hi David,

    I've analyzed the Wireshark capture you have sent and I see the problem you are describing - The NDK sends packet #67197 to the PC, but the PC never gets it (I guess it's dropped somewhere in your setup).  The NDK then continues to send packets/data to the PC, but since the PC didn't get packet 67197 it then responds to each of these with a duplicate ACK packet.

    What I noticed in the caputure, which seems very interesting, is the number of bytes the PC acknowledges (at #67222) after receiving the retransmit from the NDK (at packet #67221).

    Notice that the previous ACK from the PC at #67220 shows that the PC has received 22,780,241 bytes so far from the NDK. But then, when the PC receives the NDK's retransmit packet, the next ACK the PC sends (at #67222, the ACK of the NDK's retransmit), the ACK jumps to a total of 22,788,433 bytes.  This is a difference of 8K bytes, a very interesting number.

    Usually the NDK's TCP transmit buffer size is configured to be size 8,192 bytes.  I'm suspecting that the NDK is waiting to send out the entire contents of its TCP send buffer _before_ it retransmits the data.  Can you check to see what the TCP transmit buffer size is in your application?

    Also, can you try an experiment?  Assuming your TCP TX buffer is set to 8K, can you try to lower its size, maybe try changing it to be 4K instead of 8K?  Then re-run your test. 

    I'm wondering if you will then see the ACK increase by 4K bytes once the retransmit is received on the PC side.  If so, this would support the suspicion I have that the full contents of the send buffer are being dumped before the retransmit is sent.  Similarly, you could try increasing the buffer to see if you see the ACK increase matches the size you changed it to.

    Another thing to check are the NDK stats structs, the global variables ips, udps, tcps, raws.  You should check the NDK statistics struct for TCP at the time of the retransmission?  You can enter "tcps" into the expressions window of CCS to see the stats.

    Steve 

  • in reply to Steven Connell
    Intellectual 475 points

    Steve,

    I am having trouble capturing a Wireshark dump with the xmit buf set to 2048 (from 8192), as the failure is intermittent and I can't get a good method to trigger overnight. The change itself still shows the problem, and dropping it to 1024 will eventually crash the system. What does correct the problem is changing the periodic timer from 100ms to 20ms, although it does add additional CPU loading. I will post tcps stats if/when I capture Wireshark; should I be looking at 'SndRexmitPack' ? Thanks for your help.

    Regards,

    Dave

     

    PS Why did the forum take 88 hrs to notify me via email about an update to this post?

     

  • in reply to David Crose
    TI__Mastermind 45025 points

    Hi David,

    Any update on the new capture?  I believe you can configure Wireshark to break the capture up into multiple files (to prevent Wireshark from hanging on large captures).  Note also that you could also try increased buffer sizes for the TCP transmit buffer (increase from 8192 to 16384, for example).

    David Crose said:
    dropping it to 1024 will eventually crash the system

    This concerns me ... can you describe what the crash you are seeing is??

    David Crose said:
    should I be looking at 'SndRexmitPack' ?

    Yes, that's the number of retransmit packets sent.  Also, just keep your eye on any stat value that's > 0, as it could provide a clue.

    David Crose said:
    PS Why did the forum take 88 hrs to notify me via email about an update to this post?

    No idea, however I've seen this happen from time to time in the past.

    Steve

  • in reply to Steven Connell
    Intellectual 475 points

    Steve,

    I have been away so no update, but will try again later this week. I also got no notification via email about your recent post so forgive my late response.

    Regards,

    Dave