• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 99 subscribers
  • Views 782 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.

DM648 dropping udp packets

krishnamaiden
Prodigy 155 points


Hi All,

I am building an application that receives a udp stream with RTP data payload. I am on a private network with just the EVM dm648 and my workstation. I am using NDK ndk_2_20_06_35 with the NIMU compliant hal libraries released with NDK2.00.The UDP packets are streamed from my workstation via VLC media player. I am streaming a 10mbps clip 720x480 MPEG2 clip.

The issue I am facing is that when the UDP packets received in my application are parsed for the RTP payload sequence numbers, a packet drop is reported(some packet sequence number missing). This meant that some packets are dropped (50 packets of every 40000 received packets). Wireshark does not report any loss of packets on the network. To debug the issue further i did the following

  1. Increased UDP receive socket buffer to a comfortable large size(512k).
  2. Dumped the UDP statistics available in the NDK (udps). The statistics are as below
  3. RcvTotal       = 0000034507
    RcvShort       = 0000000000
    RcvBadLen      = 0000000000
    RcvBadSum      = 0000000000
    RcvFull        = 0000000000
    RcvNoPort      = 0000000741
    RcvNoPortB     = 0000000000
    SndTotal       = 0000000000
    SndNoPacket    = 0000000000. As RcvFull is set to zero I am assuming that the UDP recv buffer size if not an issue.
  4. the variable 'memory_squeeze_error' present in the ethernet hal library Ethdriver.c is not incremented, which led me to believe that the PBM is also not an issue.
  5. The finally the CPSW 3G register "RXSOFOVERRUNS"  indicating start of frame overruns was read and the value turned out to be 207. (this value kept varying based on the bit-rate of the clip being streamed).

To debug this further started using the benchmark udp testee application (ndk_2_0_0\packages\ti\ndk\benchmarks\copyUDP\testee\dm648) and added the print of the "RXSOFOVERRUNS" register at the end of the application. The here also is set as a non-zero value.

The question I have is

  1. How can i avoid the RXSOFOVERRUNS errors ? (Please note I only receive in my app i do not transmit data over a socket).
  2. Is one 10mbps stream too much to handle for the CPSW 3g ? I am writing the application to receive 3 10mbps streams.

Regards

Krishna

  • 0
    TI__Expert 5000 points

    Hi,

    I am not working on NDK but these are some generic queries/suggestions which you can verify if not already done.

    What is the UDP packet size? Are you sending packets with size greater than MTU/payload?

    If so, can you try sending packets lesser than MTU size & check.

    Also can you check with client example & testudp as suggested below-

    http://e2e.ti.com/support/embedded/bios/f/355/t/121331.aspx

    Also how are you increasing socket buffer size? Using setsockopt()? You can refer to the below link if required-

    http://e2e.ti.com/support/embedded/bios/f/355/t/126152.aspx

    Thanks,

    Prathap.

  • 0 in reply to Prathap Srinivas
    Prodigy 155 points

    Hi Srinivas,

    Thanks for your reply. Please find he answers to your query as below

    • The UDP packet size as seen on wireshark is 1370 bytes. VLC media player is not sending any packets greater than the MTU size.
    • I have not tried that specific app that the link refers to but have tried another app from the same release at ndk_2_0_0\packages\ti\ndk\benchmarks\copyUDP\testee. This app also shows the same issue that i am seeing.
    • Regarding increasing the size of the buffer I am using setsockopt to increase the size of the buffers as with default values 8192 the buffers overflow (indicated by the udp statistics).

    Regards

    Krishan

  • 0 in reply to krishnamaiden
    TI__Intellectual 1645 points

    Krishan,

    I am not familiar with the NDK, but I am familiar with the cpsw3g module.
    What you are describing would make me think that you are exceeding one or more of the FIFO capacity.
    I would check that flow control is enabled. Is 'cpsw3g_SetSwitchFlowControl' invoked at all?

    Flow control is especially important between the switch and the host port.

  • 0 in reply to Benoit Parrot
    Prodigy 155 points

    Hi Benoit,

    After adding the call to 'cpsw3g_SetSwitchFlowControl' in my API unfortunately the packet drops are still present. I am not sure if I am missing something configuration because even after calling this API the CPSW register  'TXPAUSEFRAMES' is being read as zero. I am receiving on port 1 my setting for that port are as below

    • P1_RX_MAX_BLKS = 6
    • P1_TX_MAX_BLKS = 14
    • P1_RX_BLK_CNT  = 2
    • P1_TX_BLK_CNT  = 4 
    • P1_P0TX_THRESH = 11
    • P1_P2TX_THRESH = 4
    • GMAC1->RX_CMF_EN = 1
    • GMAC1->RX_CSF_EN = 1
    • GMAC1->RX_CEF_EN =1
    • GMAC1->TX_FLOW_EN = 1
    • GMAC1->RX_FLOW_EN = 1

    Port 2 FIFO setting are as below

    • P2_RX_MAX_BLKS = 4
    • P2_TX_MAX_BLKS = 16 
    • P2_RX_BLK_CNT  = 4
    • P2_TX_BLK_CNT  = 16

    The CPSW_CONTROL register reads a 274.

    My the P1 flow control enabled ?

    Regards

    Krishna