[参考译文] AM6442：ipc_rpmsg_echo 延迟

您好、Fan、从文档中、我们拥有：

AM64x MCU+ SDK：数据表

我正在检查是否有任何可用的代码或有关如何计算此基准测试的指导

谢谢您、

Paula

您好：

基准测试源代码

我将从 Linux 开发人员的角度进行评论。 不要惊讶、我会将您链接到我编写的一些 Linux 代码。

源代码只在 git repo 中、不在特定于处理器的 SDK 中。 此处：
https://github.com/TexasInstruments/mcupsdk-core/tree/next/test/drivers/ipc_notify 
https://github.com/TexasInstruments/mcupsdk-core/tree/next/test/drivers/ipc_rpmsg 

请记住、这些测试报告对解决您的问题没有帮助、即您了解长时间（即具有统计显著性）测试运行中最坏情况下的延迟。 他们只讨论了 10,000 次跑步的平均往返延迟。

对于 Linux 客户、 我刚刚发布了 rpmsg_char_benchmark 应用程序、可用于了解特定 Linux 系统和 MCU+内核内的 RPMsg 性能：
*发送 1 到 496 之间任意数量的字符的性能
*平均往返延迟,最坏情况下的往返延迟,带有完整行为图的直方图
*执行 10 万亿到 1 万亿之间的任意次数（实际上不建议,在 Linux 和 MCU+内核之间执行 1 万亿次运行需要一个月以上）

https://git.ti.com/cgit/rpmsg/ti-rpmsg-char/tree/examples/README

此处的输出示例：
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1410313/am6442-communication-latency-issues-between-a53-and-r5-in-a-linux-rt-system/5434861#5434861

仅 MCU + SDK 测试结果如何？  

RPMsg IPC 9.2 中有一些错误已在后续版本中修复 — 最大的一个错误是，如果 RX 缓冲区一直填满、RPMsg 通信将锁定（我认为 16 条 RPMsg 消息是默认大小？）。 由于您一次只发送 1 个 RPMsg、因此我不希望您遇到该问题。

这显然看起来像是软件错误或软件行为问题、而不是 IPC 延迟问题。 您是否观察到任何模式？ 例如、您是否总是看到在发送一定数量的消息后延迟数字上升？

此致、

Nick

嗨、Nick
感谢您提供这个想法。 我每次发送 1024 个字节、我已经将缓冲区和缓冲区大小设置为最大值：16 个缓冲区、总大小为 1152 个字节。 现在我要做的操作是在 1ms 中断函数内、A53_00 内核循环发送 1024 个字节乘以操作、而 R10 内核接收数据。 我目前观察到的现象是、在程序启动开始时、发送消息的时间大约为 2 3 μs。 不过、在几秒钟内、它会突然增加到 300 多 000 μs、然后一直保持在这种高延迟。 我认为、当通信尚未完全建立时、消息会直接进入 IPC 缓冲区、因此是 2 3 μs 时序。 但当缓冲器耗尽时、延迟跳至大约 300ms。

此致、

平安