[参考译文] AM6442：CODESYS 性能问题

您好 Manuel、

线程所有者 将在3月的剩余时间内离开办公室。 如果您没有收到回复、请在4月初对该线程执行 ping 操作。

此致、

Nick

您好：

我还指给客户这一类似主题： (+) PROCESSOR-SDK-AM64X：XDP 支持-处理器论坛-处理器- TI E2E 支持论坛

遗憾的是、 将 ksoftirqs 优先级更改为 FIFO 52 并未改善最大周期时间。

您能帮助调试这种原因吗？

此致
Manuel

您是否联系过 CODESYS？ 对于1GHz 双核 A53、其预期性能是多少？ 逐步了解他们和他人拥有的所有指导：

https://content.helpme-codesys.com/en/CODESYS%20Control/_rtsl_performance_optimization_linux.html

https://www.linutronix.de/blog/A-Checklist-for-Real-Time-Applications-in-Linux 

Unknown 说：

我们有用于 CODESYS 许可的 USB 软件狗。

延迟异常值很可能与 USB 和 CodeMeter CODESYS 使用的许可证服务器有关。 您是否在没有使用 USB 的情况下运行相同的设备？ 其他许可方法、或者仅演示版本不需要 USB。 在我们的 CODESYS 测试运行中、我们看到的最糟糕的是许可基础设施和相关的 USB 驱动程序。

您使用 AM6442是否有特定原因？ 要运行 CODESYS、我建议使用 https://www.ti.com/product/DRA821U 、 https://www.ti.com/product/AM62P 或 https://www.ti.com/product/AM67 。 即使不调整 RT Linux 安装程序、这些功能也会显著改善。

 Pekka

目标是在 SoftMotion 中以1 usec 1毫秒周期时间旋转10个伺服驱动器。

这是可能的吗？

很好的澄清、我假设是1毫秒。 理论 EtherCAT 最佳性能为31.25us (微秒)。 请参阅 https://www.ibv-augsburg.de/downloads/icECAT_EtherCAT_AM64x.pdf 、其中显示了 Master_Stack_Benchmark R5内核上100us 周期时间基准测试的细分。 您还将看到500us A53 Linux 结果、因此、假设正确调整了设置、则可能出现1ms EtherCAT 主站。

 Pekka

客户 已在没有 USB 加密狗的情况下测试了许可、但结果没有太大变化。

这是通过 USB 许可：

这不包括：

如果他们使用自己的环境和工具链重新编译 CODESYS、会有什么不同吗？

此致
Manuel

第一个问题 CODESYS 说什么？

第二个问题为什么是 AM64x？ 这是 TI 产品系列中功能更强大的器件的原因。 在所有 TI AM6x 产品系列中、AM64x A53 Linux 性能是最差的。

Unknown 说：

如果他们使用自己的环境和工具链重新编译 CODESYS、会有什么不同吗？

CODESYS 是一种黑盒二进制文件、据我所知、它们不允许客户访问源代码。

从几个屏幕截图中、我看到两者看起来都符合1000us 的周期时间？ 如果没有 USB 转换器、与1429相比、跑步看起来很短、只有370秒、但无论如何、这两种模式都符合1000us 的要求。 据我所知(他们当然应该咨询销售 CODESYS 的供应商)、"最长周期时间"是最坏的情况、当它低于所需的周期时间时、即满足计划。

 Pekka

基于 DMIPS、使用 AM6442的设计已经完成、与之前使用的 Zynq 解决方案相比、性能预计会更好(内核时钟更低)。

问题是环路中只有一个器件才能达到1ms 周期时间。
使用8个器件时、性能降至~3ms：

这是他们的完整任务优先级列表：

R5F 和 A53之间没有运行的 IPC。

root@plcnext：~# uname -A
Linux plcnext 6.1.83-rt28-ti-RT-g96b0ebd82722 #1 SMP_RT Preempt_RT、5月13日、星期一、23：06：24 UTC、2024 AArch64 GNU/Linux

在与 Thomas Schneider 的讨论中、他提到我们在连接了3个驱动器的 AM6442上看到了~300us。

CODESYS 的整体配置似乎有问题？

此致
Manuel

好的、所以似乎距离目标还有很长的路要走。 对于基准器件、您是否有更具体的细节、什么是 Zynq 器件？ 比如带有 Cortex-A9的 Zynq-7000或带有 A53的 UltraScale+？ 这些步骤和内核配置用于实现所需性能、是否遵循了所有相同的步骤和内核配置？

它应该归结为"正常"RT 调优和延迟优化。 这是像 Linutronix 和 BayLibre 这样的公司很好的地方。 或其他高端 Linux 承包商。 并提供了几个起始步骤。

1.确保中断处理不是问题。 PREEMPT_RT 使用 ksoftirq 来处理中断(https://bootlin.com/doc/training/preempt-rt/preempt-rt-slides.pdf )。 他们的优先事项是什么？ 类型：

ps aux | grep ksoftirq

查看两个 ksofirqs (每个内核一个)的 PID。 在我们的 SDK 中、它们默认不是 RT 或 FIFO 调度。 更改为高优先级、如 FIFO 为10。 使用如下命令(假设 PID 为13和27)：

chrt -f -p 10 13 
chrt -f -p 10 27 

2.在完整的任务优先级列表中,我看到 PRI+RT 列中 RT 优先级(负数)处有大量空。 我想90%以上的绿色材料不应该处于高优先级。 只有与 CODESYS 使用的以太网接口相关的内容才应是 RT、其他所有内容都不应是 RT。 RT 是一个零和游戏,优先级来自尽可能少的高优先级,蹲下其他人,所以救护车可以通过。 高优先级越高、优先级越低。 在 Zynq 上获取相同的打印输出并进行比较。

3、使系统精益化。 根据经验、Linux 内核越小、RT 性能越好。 删除您不需要的所有服务和内核模块。

4. https://www.linutronix.de/blog/A-Checklist-for-Real-Time-Applications-in-Linux 开始走下坡路。

 Pekka

您好、感谢您加入我们的论坛、感谢您的支持！

更改 Ksoft 中断的优先级不会提高性能。

user4068379 说：

OK、所以似乎距离目标还有很长的路要走。 对于基准器件、您是否有更具体的细节、什么是 Zynq 器件？ 比如带有 Cortex-A9的 Zynq-7000或带有 A53的 UltraScale+？ 这些步骤和内核配置用于实现所需的性能、是否遵循了所有相同的步骤和内核配置？

对于我们的旧系统、我们使用基于 Cortex-A9的 Zynq 7020。

"第二个问题为什么是 AM64x？ 这是 TI 产品系列中功能更强大的器件的原因。 在所有 TI AM6x 产品系列中、AM64x A53 Linux 性能是最差的。"

这句话对我来说很有趣。 原因是什么？ 如果我们在所有4个 R5内核和 ARM64内核之间使用 rpmsg、性能会更差吗？