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.

UDP Packet loss (dm6467 EVM)

Other Parts Discussed in Thread: TMS320DM6467T

Hello,

I am using the TMS320DM6467T evaluation board.  I see that it is labeled version C.

I am having a problem where I am dropping close to 50% of my UDP packets when using the iperf utility at 500mbps.  I need this rate to work.  I have seen other posts regarding the capability of the hardware etc. but these were dated almost 2 years ago. 

I am wondering if there is any advice on this subject.  Perhaps I did not properly enable my gigabit ethernet or something?

Here are the results from an iperf run using direct connection (no switches) between a linux box and the davinci.

 Linux client

 

[bjabkiewicz@localhost /]$ iperf -c 172.17.1.55 -u -t 20 -b 500m

------------------------------------------------------------

Client connecting to 172.17.1.55, UDP port 5001

Sending 1470 byte datagrams

UDP buffer size: 0.12 MByte (default)

------------------------------------------------------------

[  3] local 172.17.1.152 port 49022 connected with 172.17.1.55 port 5001

[ ID] Interval       Transfer     Bandwidth

[  3]  0.0-20.0 sec   454 MBytes  22.7 MBytes/sec

[  3] Sent 324001 datagrams

[  3] Server Report:

[  3]  0.0-20.2 sec   199 MBytes  9.84 MBytes/sec  15.316 ms 182027/323988 (56%)

[  3]  0.0-20.2 sec  1 datagrams received out-of-order

 

Davinci Server

root@dm6467t-evm:~/iperf-2.0.5# ./src/iperf -s -u

------------------------------------------------------------

Server listening on UDP port 5001

Receiving 1470 byte datagrams

UDP buffer size:  108 KByte (default)

------------------------------------------------------------

[  6] local 172.17.1.55 port 5001 connected with 172.17.1.152 port 49491

[ ID] Interval       Transfer     Bandwidth        Jitter   Lost/Total Datagrams

[  6]  0.0- 5.2 sec  53.4 MBytes  85.5 Mbits/sec  15.463 ms 41610/79725 (52%)

[  6]  0.0- 5.2 sec  1 datagrams received out-of-order

[  7] local 172.17.1.55 port 5001 connected with 172.17.1.152 port 52790

[  7]  0.0-20.2 sec   198 MBytes  81.9 Mbits/sec  15.386 ms 182446/323547 (56%)

[  7]  0.0-20.2 sec  1 datagrams received out-of-order

[  6] local 172.17.1.55 port 5001 connected with 172.17.1.152 port 49022

[  6]  0.0-20.2 sec   199 MBytes  82.5 Mbits/sec  15.317 ms 182027/323988 (56%)

[  6]  0.0-20.2 sec  1 datagrams received out-of-order

I have also tried to adjust the values in the /proc/sys/net/core wmem and rmem as well as the /proc/sys/net/ipv4 udp_rmem/wmem/mem files on the davinci.  This did not improve performance.

  • Sorry, I sent it too quick!

    Thanks for you help :)

  • Hi,

    Is there anyone available to advise?  If this has been a problem for two years I suspect there is a solution and I am just not finding it.  It is essential that I get my Ethernet drivers working reliably for UDP with the ability to receive 500mbps.

    Thanks again!

    Brandy

  • Hi,

    We have started looking into it. Will update soon.

    Regards, Sudhakar

  • Hello Sudhakar,

    Thank you for taking this on.  I have actually posted this issue twice in order to get some attention.  Here is the other link for your reference, it has slightly different (but additional) information, including my bootlog that shows it seems to negotiate gigE:

    http://e2e.ti.com/support/embedded/f/354/t/93419.aspx

    I really appreciate any help you can give.  I have begun looking through the driver code, but as I am sure you can imagine it is slow and often fruitless.

    thanks,

    brandy

     

     

     


  • Hi Brandy,

                 The high performance cannot be obtained due to the limitations on the CPU horse power and the TCP/IP stack overhead in linux.  Please check the following link for the performance figures achieved on 6467T.

    http://processors.wiki.ti.com/index.php/DaVinci_PSP_03.02_GA_%28r37%29_Release_Notes#Performance_-_DM6467T_EVM_.28495_MHz.29

    You can see that the maximum performance is around 153.1 Mbits/s  when ARM is running at  500 MHZ . So, packet loss at 500 Mbps is expected.

    I tested for 100/200 Mbps and the packet loss was negligible.

    Regards,

    N.sugumar

  • So, what you are saying is that it will be impossible for me to receive raw video streams over the ethernet at the necessary rate of 500mbps even though it is advertised that this part supports 1000mbps?

    Please tell me, is there way to increase the clock or increase the stack size?  What can I change, even if I need to change the evm to make this work?

  • Hi Brandy,

       You can see from the datasheet the maximum clock rate of ARM supported on dm6467t is 500 MHZ.

    http://focus.ti.com/docs/prod/folders/print/tms320dm6467t.html

       Clock cannot be increased any further as ARM is already configured to run at the Maximum possible speed. I have no idea on other EVMs.

    Regards,

    N.Sugumar

     

    PS:  I just did a google search and found this useful info. Hope it will be useful. But I have no idea about it :)

    http://software-dl.ti.com/dsps/dsps_public_sw/ezsdk/latest/exports/C6A816x_AM389x_EVM_Quick_start_guide.pdf

  • Hello,


    I found this "throughput" document showing that it can handle 908mbps.  Please show me how to change my board to behave like this document shows:

    http://focus.ti.com.cn/cn/lit/an/spraaw4b/spraaw4b.pdf Page 38

    Thank you.

     

  • Brandy,

    As I understand, the code that hits 900+ mbps is running in a tight-loop without an OS, and is protocol-agnostic code which does not even use interrupts.

    With a real OS in place and with the overhead from things such as:

    1) Interrupts and context switching
    2) Copies from kernel space to user space for each packet
    3) TCP/IP checksum on each packet

    The same throughput is unobtainable. As Sugumar suggests the maximum 'real-world' throughput we see is ~150Mbps.

    I am currently checking to see if there is any way to increase throughput through any sort of trick, and will let you know what I find.

  • Hello,

    Yes, we have also determined that that must have been the case (no OS running).  Since re-writting the entire system for no OS is not really an option, we have moved on to another thought.  We are going to try to get the data across in VPIF-raw mode.  Do you have any sample applications that do this?  Also, we are wondering what might be the best way to test this on the EVM.  Right now, we can see that the VPIF with video decoder (ie using component inputs/outputs) runs 1080p at 60fps without a problem.  If we switch to raw mode, can we expect the same performance?  (should perhaps start a different thread for these questions?)

    Any thoughts would be appreciated.

    Brandy