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.

C6678 UDP速率问题



各位专家大牛:

我用C6678的自带例程helloword例程测试网络,使用socket编写的UDP每包1400字节数据测试,在100Mbps带宽下与PC机通信测试,如果DSP单发或者单收UDP,速率均能达到90Mbps左右;如果DSP接收一包UDP数据,立刻反馈一包UDP数据给PC上位机,再接收下一包,再返回一包,循环测试,PC上位机是先发送一包再接收一包反馈,一直循环,这种情形下UDP速率只有10Mbps,请问这个速率慢可能与什么有关系??

  • 请问PC端上用的是什么软件接收发送数据包?看一下是不是PC端的设置问题。
  • PC机使用的是VS2015开发的WIN32程序,两个DSP之间采用这种测试结果一样,只要是UDP一发一收的测试流程,速率就会特别低,加大包长度是会有改善,但是现在想弄明白的是会有什么这个流程会比但测试发送和接收的速率差这么多,请问是否跟QMSS/PA这些的配置有关,是否发送队列单个包发送会存在延时或者接收中断触发会慢?
  • PC机使用的是VS2015开发的WIN32程序,两个DSP之间采用这种测试结果一样,只要是UDP一发一收的测试流程,速率就会特别低,加大包长度是会有改善,但是现在想弄明白的是为什么这个流程会比单个测试发送和接收的速率差这么多,请问是否跟QMSS/PA这些的配置有关,是否发送队列单个包发送会存在延时或者接收中断触发会慢?
  • loopback模式会有这个问题吗?
  • 这个模式没有测试,我们的环境是与其他处理器的网络通信,对端网络我们与其他处理器(型号不清楚)的测试可以达到5MB/s,不会出这个问题;然后我们又用PC机与DSP做测试,速率仅为1.7MB/s,问题现象一致;所以现在怀疑可能的原因是在DSP这边,想请教一下是否有什么其他驱动配置或者方法解决这个问题?
  • 请在PC上运行NDK winapps里的testudp测试一下,用Wireshark看一下速度。
    请参考下面的帖子,尝试加大 NDK buffer sizes 和no. of PBMs packets看能否提高速度。
    e2e.ti.com/.../575081
  • 1.单测试接收和发送速率是能达到12MB/s 的,这个没有问题;
    2.在发送一次接收一次的循环场景下,用1400字节的包大小测试只有1.5MB/s;修改NDK加大包大小之后发送10KB的包大小是可以8MB/s,用1400字节的包大小还是1.5MB/s
    3.现在因为我们的应用场景只能是1400字节的有效包大小,固定发送130MB,如果单纯加大每包的数据量,总体的数据量也会加大,最后发送的时间还是超出预期的,所以这个解决方案目前不可行
    4.请教一下,按照1400字节的包大小,一发一收的 情况下官方测试速率能达到多少?是否也是1~2MB/s左右?
    5.NDK协议栈或者PKTDMA的发送和接收,在UDP一发一收的情况下是否需要修改什么配置?我们DSP测试使用的都是例程设置,没有做过修改
  • 可以用NDK winapps里的testudp测试一下,用Wireshark看一下1400字节速度。
  • 1. 百兆模式下,1400字节一发一收的测试还是1.5MB/s
    2. UDP连续发送的情况下接收和UDP发送一包去接收,DSP的处理有什么不一样吗?是连续发送的情况下单个接收中断可以处理多个UDP包吗?
    3.或者是单个UDP包发送queue触发发送时间长?多个UDP包连续发送会一次中断发送全部?
    目前在一发一收的情形下还是不太清楚时间是哪个环节慢了,请问是否是中断响应处理就是慢,没有办法优化?
  • 请问用的NDK是哪个版本?是最新的吗?
  • CCS是5.5,NDK是ndk_2_25_01_11
  • 另外,因为我们应用可能就是简单的点对点的数据传输,所以想能不能不经过gbe switch和packet DMA这些控制器,也可以不用NDK协议栈,而是直接实现serdes->sgmii->mac这种数据传输?有没有这种的参考例程?
  • 可以参考 一下置顶帖里分享的STK里的例程。
    e2echina.ti.com/.../47664
  • 感谢分享!这个我试了一下GE的测试,DSP之间的测试一发一收的情况下,为什么首先发起发送数据包的DSP在循环发送和接收26个数据包之后就再也接收不到了?定位了一下有以下几个现象:
    1.作为发送的DSP的中断后处理GE_Message_ISR()一直没有触发了,正常情况下发现会一直自动触发
    2.作为发送的DSP尝试手动再次发送一个数据包,作为接收的DSP可以正常接收,也正常发送了,但是对端的DSP始终没有触发GE_Message_ISR()中断
    3.每个DSP都serdes自循环测试,可以发送很多数据包,我测试了10000包都正常
    请问这个可能是什么问题?
  • 我把您的问题升级到E2E上了,请关注下面帖子的回复,谢谢!
    e2e.ti.com/.../tms320c6678-udp-throughput-is-slow-when-dsp--pc--dsp
  • 请按照下面工程师的建议试试:

    I suggest customer try to send packet directly in driver layer and project's task count reduce to enough.

    step1:creat a send task;

    step2:init udp packet raw data "pktMatch array in cppi_qmss_mgmt.c",formart fixly,such as "00 01 02 03 04 05 06 07" ;

    step3:init cppi host descriptor,inited by raw data.

    step4:push host descriptor into qmss queue 648.


    while(1) execute step1 to step 4,check dsp->pc packet rate,view windows control panel network rate maybe exceed 500Mbps.

    later,create a receive task in dsp,pc send packet to dsp,view again windows control panel network rate?



    suspect:

    1、is there drop pkts because of exhausted buffer?

    2、is there some delay or task_sleep?

    3、is there other task enter into while(1) loop branch?

    4、how to confirm the packet not drop in PC forward step?



    NOT professional tips,good luck.
  • 谢谢!
    1.我熟悉了一下底层,还是需要请教一下,step3/step4关于host descriptor的修改在哪里?
    2.可能怀疑的几点,首先我用户层创建的就一个task,系统后台的没有去看,任务里并没有sleep之类的操作;这个速率测试我用PC与DSP之间测试过,用DSP于DSP之间也测试过,下面是我任务里的测试循环:
    for(index = 0;index<10000;index++)
    {

    status = sendto(socket_udp,(char*)udp_cache,rcv_len,0,(PSA)&to_server,to_server_len);

    rcv_len = recvfrom(socket_udp,(char*)udp_cache,rcv_len,0,(PSA)&str_tmp,&to_server_len);


    }
  • 还是需要请教一下:
    step2:init udp packet raw data "pktMatch array in cppi_qmss_mgmt.c",formart fixly,such as "00 01 02 03 04 05 06 07" ;

    step3:init cppi host descriptor,inited by raw data.

    step4:push host descriptor into qmss queue 648.
    1.第二条中的数据格式修改不太明白,原先的是一维数组格式{0x10,0x11,0x12......},这种跟建议中的一样吗?
    2.第三条、第四条中的修改还是没找到在哪个文件里,能帮忙发一下是哪个文件或者是哪个函数吗?
    谢谢!!
  • 在e2e上把您的问题更新了,您后续有什么问题的话,也可以直接在我发的帖子上回复。

  • 好的,非常感谢!!