• 状态 Resolved
  • 已锁定 已锁定
  • 回复 9 回复
  • 订户 0 订户
  • 视图 313 视图
  • 用户 0 会员在此处
选项
选项
相关

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.

[参考译文] Linux/AM5728：高比特率下的 CPSW 驱动程序故障

admin
Guru**** 2609555 points
Other Parts Discussed in Thread: AM5728

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/652890/linux-am5728-cpsw-driver-failure-at-high-bit-rates

器件型号：AM5728

工具/软件：Linux

您好！

我在定制板上使用内核4.4.41-rt50-g968d071ce9。

我的板通过220Mb/s 的网络端口接收数据、没有问题、但当我将速率提高到370Mb/s 时、

一个多小时后会发生看门狗超时、并且所有未来的连接都将丢失。  Ping 无效。

如果您继续提高该速率、此时间将会更短。

重新插入网络端口时没有问题。

以下是打印的消息(仅显示一次)：

e2e.ti.com/.../1263.log.txt

这是我使用某些命令进行审阅的结果。

e2e.ti.com/.../4532.dmesg.txt

我尝试使用04.00.00 SDK、最大速率仅为200Mb/s。这不适合我使用。

谢谢、

  • 0
    TI__Guru**** 2609555 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    请遵循此检查清单并将结果发布在以下位置： processors.wiki.ti.com/.../5x_CPSW
  • 0
    TI__Guru**** 2609555 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好 、Biser、

    我已将请求的信息附加到此邮件中。  

    e2e.ti.com/.../cpsw_5F00_triage.txt

    谢谢。

  • 0
    TI__Guru**** 2609555 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    您好！

    感谢您发布鉴别分类结果。 结果中的数据目前看起来不错、因此我还有一些其他问题。

    网络看门狗超时来自由于传入数据包而变得无法控制的发送队列。 看门狗消息将只打印一次、可能会进一步超时。 每次超时驱动程序被重置时、每次重置都会导致网络流量瞬时丢失。

    能否提供您要测试的网络图？

    您需要的网络吞吐量是多少？ 以下是最新 RT 内核的发布结果。 这些结果低于非优先级 RT 内核。

    processors.wiki.ti.com/.../Processor_SDK_Linux_RT_Kernel_Performance_Guide

    我是否正确地知道您使用 iperf 来测量网络吞吐量？ 如果是、您可以发布您正在使用的命令行吗？

    您是否正在运行 TI 内核配置？

    您是否调整了任何线程优先级、处理器上是否运行了任何其他应用程序？

    此致、
    Schuyler
  • 0
    TI__Guru**** 2609555 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    Schuyler、您好、  

    感谢你的答复。

    您所说的结果：每次重置都会导致网络流量瞬时丢失。

    我们需要大约350MB/s 的网络吞吐量

    内核配置我指的是"tisdk_am57xx-EVM-RT_defconfig"、在网络上没有变化。

    我们的程序尚未修改线程优先级，同时运行 Java 程序，它们构成了一个完整的程序。

    下面是我的测试命令和网络图以及使用的内核配置文件。

    e2e.ti.com/.../test_2D00_result.docx

    e2e.ti.com/.../3362.config.txt

    谢谢、

    更好

  • 0
    TI__Guru**** 2609555 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    您好、
    感谢您发布其他测试结果。

    从发布的测试结果文件中：
    _________________________________________________________
    root@am57xx-EVM：~# iperf -c 192.168.1.22 -t 60 -w 8. <-- 这是一个8字节窗口大小、您是指8KB 窗口大小吗？
    警告：TCP 窗口大小设置为8字节。 小窗口尺寸
    会导致性能不佳。 请参阅 Iperf 文档。
    _________________________________________________________


    如果您需要8KB 的窗口大小、可以通过此更改重新运行测试吗？

    iperf -c 192.168.1.22 -t 60 -w 8KB

    此致、
    Schuyler
  • 0
    TI__Guru**** 2609555 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    Schuyler、您好、  

    这是我重新测试的结果。

    e2e.ti.com/.../re_2D00_test.txt

    我认为这不会产生任何影响、因为我使用"iperf -c 192.168.1.22 -d -t 60"命令测试的带宽应该足够了。

    我认为该问题应该是驱动程序错误？ 您是否分析过此驱动程序？

    我在论坛上发现了几个类似的帖子、描述了这些问题是相似的。

    谢谢，

    更好

  • 0
    TI__Guru**** 2609555 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    您好、

    我同意您列出的命令已足够、默认值应为64KB。 64KB 的窗口将具有更高的性能。 您使用不同的窗口大小执行的重新测试确认了这一点。

    驱动程序在每个版本中进行测试、并在每个版本上测量 cpsw 吞吐量。

    重新测试是在您的应用程序同时运行的情况下完成的吗？

    您能否在不运行应用程序的情况下在电路板上测试 iperf 性能？ 性能如何、在该配置中是否出现网络看门狗超时？

    对于您尝试实现的数据速率、它是 UDP 还是 TCP 流量？ 您提到过吞吐量、电路板是否仅以370Mbps 的速率接收数据？ 是否有发送比特率要求？

    在先前的测试结果文档中、看起来已经尝试过多个内核版本、您是否能够尝试4.2 SDK？

    您能否将链接发布到您所说的其他论坛帖子、这些帖子与您看到的问题类似？

    此致、
    Schuyler
  • 0
    TI__Guru**** 2609555 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    Schuyler、您好、  

    我尝试了4.2 SDK (非 RT 版本)。

    问题已消失。

    我在之前的版本(SDK3.0)测试中再次尝试、效果也很好。

    我怀疑这可能是因为应用程序中使用中断会影响实时内核。

    你怎么看？

    谢谢、

    更好

  • 0
    TI__Guru**** 2609555 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    您好、

    我很高兴听到问题得到解决。

    我只能笼统地说应用程序对内核的影响。 RT 和非 RT 内核之间的一个主要区别是调度策略。 在非 RT 中、使用的完全公平调度程序将确保所有线程都运行。 在 RT 内核中、可以根据应用程序使用的调度策略(RR、FIFO)来启动线程。 您的观察结果可能是正确的、因为应用程序没有为内核提供足够的时间来防止网络堆栈和驱动程序遇到您遇到的超时。

    不过、我的一个问题是、您报告的问题之一是能够在一段时间后 ping AM5728。 如果您再次遇到这种情况、请报告。 同时、我们将考虑该线程是否已解决。

    此致、
    Schuyler