[参考译文] AM62A7-Q1：EdgeAI：长时间以高负载运行 EdgeAI 流水线时冻结

尊敬的 Bas：

您能否分享您尝试运行的管道？ 它是否具有多个解码器实例？ 如果是、则将在今年晚些时候发布的版本中解决另一个相关问题。

请查看以下 JIRA： https://sir.ext.ti.com/jira/browse/EXT_EP-12787

您链接的问题是、它从四个文件输入切换到一个文件输入、以减少解码器实例的数量。 请检查是否使用单个输入、使用 TEE 将其拆分并查看流水线是否稳定。 如果是、则很可能是问题所在。

此致、
Jay

尊敬的 Jay：

我们同时运行两个编码器实例。 我已经做了一些调试与 Brandon Brnich 类似的问题 . 这已经解决、这是一个新问题。

我们使用类似于以下流水线：

e2e.ti.com/.../0181.pipeline.txt

我们将 UDP 接收器用于 RTP 路径、但这显示了我们流水线的总体结构。 我们有两个不同的输出流、因此需要两个编码器实例。

此致、

Bas Vermeulen

尊敬的 Bas：

您能否提供现有线程的链接？ 我还在与我的团队核实、看看是否会在此处应用上一个修复程序。 请期待明天作出响应。

此致、
Jay

你好 Jay Goyal ,

在此处可找到现有线程。 解决了编码器中的崩溃（这与处理发送给编码器的请求时的竞态条件有关）。

我已经在链接线程的末尾加入了应用于各种内核版本的修复程序。

这个问题可以用我在上一个答复中添加的脚本重现；当流水线挂起时、我在 dmesg 中收到以下消息：

[24365.808244] virtio_rpmsg_bus virtio1：入站 msg 太大：(20,336)

安装程序没有再运行,所以我无法将 virtio 连接到远程处理器,我正在复制它,并返回给你的那些信息。

此致、

Bas Vermeulen

尊敬的 Bas：

我已将您的问题分配给 GStreamer 专家。 他们目前已离职。 因此、请预计下周中旬之前做出回复。 之后、请随时在这里 ping 通。

此致、
Jay

您好、  

我正在从事与 Bas Vermeulen 相同的项目 。 我想分享一些其他发现、这些发现可能有助于我们更快地达成解决方案。

我们最初在运行自定义固件的定制电路板上发现了此问题。 从那时起、我们能够使用 IMX219 Raspberry Pi 摄像头和 TI 提供的图像在 EVM 上重现问题 tisdk-edgeai-image-am62a-evm-11.01.07.05 。 使用以下 GStreamer 流水线可重现此问题：

gst-launch-1.0 -v -e v4l2src device=/dev/video-imx219-cam0 io-mode=5 \
        ! video/x-bayer, width=1920, height=1080, format=rggb, framerate=30/1 \
        ! tiovxisp sink_0::device=/dev/v4l-imx219-subdev0 sensor-name="SENSOR_SONY_IMX219_RPI" \
                dcc-isp-file=/opt/imaging/imx219/linear/dcc_viss.bin \
                sink_0::dcc-2a-file=/opt/imaging/imx219/linear/dcc_2a.bin format-msb=11 \
        ! queue max-size-buffers=1 leaky=0 \
        ! tiovxmultiscaler name=videotee \
videotee. \
        ! queue max-size-buffers=1 leaky=0 \
        ! video/x-raw, width=1920, height=1080, framerate=30/1 \
        ! v4l2h265enc \
        ! h265parse \
        ! fakesink name=FHD_RTP_STREAM_1 \
videotee. \
        ! queue max-size-buffers=1 leaky=0 \
        ! video/x-raw, width=1920, height=1080, framerate=30/1 \
        ! tiovxmultiscaler name=hdvideotee target=1 \
hdvideotee. \
        ! queue max-size-buffers=1 leaky=0 \
        ! video/x-raw, width=1920, height=1080, framerate=30/1 \
        ! tiovxmultiscaler name=stage2 \
        ! tiovxmultiscaler name=stage3 \
        ! v4l2h265enc \
        ! h265parse \
        ! fakesink name=FHD_RTP_STREAM_2 \
hdvideotee. \
        ! queue max-size-buffers=1 leaky=0 \
        ! video/x-raw, width=960, height=540, framerate=30/1 \
        ! fakesink name=MOTION_STREAM \
hdvideotee. \
        ! queue max-size-buffers=1 leaky=0 \
        ! video/x-raw, width=960, height=540, framerate=30/1 \
        ! tiovxmultiscaler target=1 \
        ! video/x-raw, width=416, height=416, framerate=30/1 \
        ! tiovxdlpreproc model=/opt/model_zoo/ONR-OD-8410-yolox-tiny-lite-mmdet-widerface-416x416/ out-pool-size=4 \
        ! application/x-tensor-tiovx \
        ! tidlinferer target="C7x1" model=/opt/model_zoo/ONR-OD-8410-yolox-tiny-lite-mmdet-widerface-416x416/ \
        ! queue \
        ! fakesink name=EDGEAI_STREAM

使用上述流水线时、错误在大约三小时后发生。 故障时间似乎与系统负载有关。 增加了更多负载时的电容 tiovxmultiscaler 元素和/或的其他实例 提德林费尔 、错误发生前的时间减少到大约一个小时。

我还有更详细的 dmesg 日志、其中显示以下内容：

[ 2289.107125] rpmsg_ctrl virtio1.rpmsg_ctrl.0.0: TX From 0x403, To 0xe, Len 116, Flags 0, Reserved 0
[ 2289.107214] rpmsg_virtio TX: 03 04 00 00 0e 00 00 00 00 00 00 00 74 00 00 00  ............t...
[ 2289.107232] rpmsg_virtio TX: 63 6f 6d 2e 74 69 2e 70 65 72 66 5f 73 74 61 74  com.ti.perf_stat
[ 2289.107231] virtio_rpmsg_bus virtio1: From: 0xd, To: 0x402, Len: 4, Flags: 0, Reserved: 1
[ 2289.107282] rpmsg_virtio TX: 73 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  s...............
[ 2289.107283] rpmsg_virtio RX: 0d 00 00 00 02 04 00 00 01 00 00 00 04 00 00 00  ................
[ 2289.107292] rpmsg_virtio RX: 00 82 38 00                                      ..8.
[ 2289.107297] rpmsg_virtio TX: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
[ 2289.107343] rpmsg_virtio TX: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
[ 2289.107358] rpmsg_virtio TX: 09 00 00 00 00 00 00 00 24 00 00 00 00 00 00 00  ........$.......
[ 2289.107399] rpmsg_virtio TX: 98 1b aa a4 ff ff 00 00 2c 15 aa a4 ff ff 00 00  ........,.......
[ 2289.107411] virtio_rpmsg_bus virtio1: From: 0xd, To: 0x402, Len: 4, Flags: 0, Reserved: 1
[ 2289.107419] rpmsg_virtio TX: f4 1a aa a4 ff ff 00 00 ec 15 aa a4 ff ff 00 00  ................
[ 2289.107428] rpmsg_virtio TX: b0 11 a3 15                                      ....
[ 2289.107430] rpmsg_virtio RX: 0d 00 00 00 02 04 00 00 01 00 00 00 04 00 00 00  ................
[ 2289.107438] rpmsg_virtio RX: 00 a2 39 00                                      ..9.
[ 2289.107473] virtio_rpmsg_bus virtio1: From: 0xd, To: 0x402, Len: 4, Flags: 0, Reserved: 1
[ 2289.107497] rpmsg_virtio RX: 0d 00 00 00 02 04 00 00 01 00 00 00 04 00 00 00  ................
[ 2289.107505] rpmsg_virtio RX: 00 52 38 00                                      .R8.
[ 2289.107542] virtio_rpmsg_bus virtio1: From: 0xe, To: 0x403, Len: 116, Flags: 0, Reserved: 1
[ 2289.107564] rpmsg_virtio RX: 0e 00 00 00 03 04 00 00 01 00 00 00 74 00 00 00  ............t...
[ 2289.107582] rpmsg_virtio RX: 63 6f 6d 2e 74 69 2e 70 65 72 66 5f 73 74 61 74  com.ti.perf_stat
[ 2289.107615] rpmsg_virtio RX: 73 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  s...............
[ 2289.107631] rpmsg_virtio RX: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
[ 2289.107647] rpmsg_virtio RX: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
[ 2289.107688] rpmsg_virtio RX: 09 00 00 00 00 00 00 00 24 00 00 00 00 00 00 00  ........$.......
[ 2289.107706] rpmsg_virtio RX: 98 1b aa a4 ff ff 00 00 2c 15 aa a4 ff ff 00 00  ........,.......
[ 2289.107721] rpmsg_virtio RX: f4 1a aa a4 ff 8c 74 ea 41 83 91 7b 8c 09 f5 81  ......t.A..{....
[ 2289.107754] rpmsg_virtio RX: c2 0c 6f 3f                                      ..o?
[ 2289.107762] virtio_rpmsg_bus virtio1: inbound msg too big: (20, 116)

问题似乎是由最后一条消息触发的、该消息的长度为 116、并且包含字符串“ com.ti.perf_stats “。
我不确定此消息的来源和发送原因。 但是、需要注意以下几点：

•tiperfstats 在这些测试期间没有运行、我想假设此消息会以某种方式相关？
•。 com.ti.perf_stats 仅当启用了 EdgeAI 路径 (tiovxpreproc + tidlinferer) 时、才存在消息。
•我看不到带有“ com.ti.perf_stats “、甚至在启用了 EdgeAI 路径的情况下也是如此。

此致、

Martijn Vogelaar

您好、

在调查源代码后、以下提交似乎引入了此附加消息：

https://git.ti.com/cgit/processor-sdk-vision/arm-tidl/commit/?id=971ab31c99083f7febfdd606333c7ccd731cba6f

此提交会修改函数 TIDLRT_getDdrStats (),该函数从 ONNX (EdgeAI) 相关的代码路径多次调用。

因此、当运行单个 tidlinferer 实例时、该消息以大约每秒 120 次的速率发出。 每个额外的 tidlinferer 实例都会以大致成比例的方式进一步增加消息速率、这可以解释为什么添加更多实例可以减少错误发生之前的时间。

在这一点上、我不清楚这一信息是直接与观察到的问题有关、是根本原因、还是仅仅是一个更大的根本问题的症状。

此致、

Martijn Vogelaar

尊敬的  Martijn 和 Bas：

感谢您孤立我们可以重现的场景、我们将尝试重现此情景。 我已经使用标准 11.1 SDK 在我这边启动了此流水线  

这些 perf-stats 数据正在 DM R5 上生成、名义上将包含 DDR 利用率 — 当然，它适用于通过 IPC 的 A53。 我预计只有在 env 变量  “TIDL_RT_DDR_STATS" 定义“定义为非零值时、才会发生这种情况、但我看到现在默认情况下已启用此功能... 如果您定义了`导出  TIDL_RT_DDR_STATS=0` in your environment before running this application, does the issue persist?

• Good find Martijn!

这个 perf stats 测量将在模型开始和模型结束时运行、因此我们可以在整个模型推理过程中捕获 DDR 流量、这意味着每个推理至少有 2 次调用（从技术上讲，每个子图）。 它只能在 tidlinferer 插件中进行此调用。

我最近注意到一些其他情况、如果启用了 LDC、流水线会在非常高的负载下停滞。 我可以在固件构建器中提供一个直接解决此问题的修复、但我希望您看看当 LDC 插件未在流水线中时问题是否仍然存在。   

BR、
Reese

尊敬的 Reese：

感谢您的快速跟进。

实际上、我在开机自检后不久就注意到了环境变量、可以确认设置TIDL_RT_DDR_STATS=0成功地阻止了消息的发送。 我目前有一条管道在一夜之间运行、看看这是否可以防止出现停顿；我明天早上将向您更新这些结果。

关于 LDC 插件：虽然我们应用中的流水线确实使用 LDC、但我为 EVM 提供的最小复制流水线不包含 LDC 插件。 这表明此问题可能与您最近观察到的与 LDC 相关的失速无关。

此致、

Martijn Vogelaar

尊敬的 Reese：

使用导出  TIDL_RT_DDR_STATS=0 来禁用 perf-stats 消息、这似乎会对我们的流水线产生积极影响。 现在它已经运行了 16 个多小时,而以前它只会在几个小时后停止。 我将在周末继续运行、以获得更多的信心、即此更改实际上解决了该问题。

在这一点上、我还不清楚这些信息本身是否促成了这个问题、还是只是揭示了一个更根本的问题。 我也不确定默认启用这些调试消息背后的原因、因此可能值得进一步研究。

此致、

Martijn Vogelaar

尊敬的  Martijn：

现在我已经在我这边运行了同样的管道~20 小时了——到目前为止没有出现任何挂起或问题、即使在后台有压力来提高 DDR 利用率也是如此。 我会让它在周末运行、同时具有较高的背景负载

使用 export  TIDL_RT_DDR_STATS=0 禁用 perf-stats 消息、这似乎会对我们的流水线产生积极影响。 [/报价]

有良好的迹象,但是的,这需要进一步调查我们的方面。 让我在内部提出这个问题。 该设置默认处于启用状态、因此 TIDL 可以按帧提供 DDR 统计信息、但这可能不是正确的方法。 我之前在应用级别没有看到这种副作用、但至少会增加不太重要的 IPC 流量、在量产应用中可能会错过这种副作用。  

---

[引述 userid=“694466" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1634249/am62a7-q1-edgeai-freeze-when-running-edgeai-pipeline-for-a-long-time-with-high-load/6312054

关于 LDC 插件：虽然我们应用中的流水线确实使用 LDC、但我为 EVM 提供的最小复制流水线不包含 LDC 插件。 这表明此问题可能与您最近观察到的与 LDC 相关的失速无关。

[/报价]

啊、好的一点、我在第一条管道中看到了、但在第二条管道中没有注意到它被移除。 请忽略该建议、然后。  

尊敬的 Reese：

很遗憾你不能在你的最后重现它 我假设您在没有导出 TIDL_RT_DDR_STATS=0 的情况下运行测试？ 您可以尝试的一件事是复制 EdgeAI 分支二次、三次甚至四次。 这将增加总负载、并因此增加 IPC 流量、这可能有助于重现问题。

在我们看来、该应用程序（导出的 TIDL_RT_DDR_STATS=0） 现在已经运行了一段时间而不会崩溃、因此问题似乎已经解决。

此外、您是否想分享用于解决 LDC 问题的固件构建器的补丁？ 我们尚未遇到此问题、但我们希望在问题出现之前主动解决此问题。

此致、

Martijn Vogelaar