女士们和先生们，
网络通信的性能和可用性对于我们计划的应用非常重要，
-特别是在高网络流量时。
因此,我们进行了一系列的测试:我们构建了应用 ENET/LWIP/ICSSG,包含
AM64x-AM64x 封装中、并启动它并在 MCU-PLUS-SDK (在 R5F 内核上)上运行、
MCU-PLUS-SDK AM64x-AM64x 封装的版本09.01.00.41于2023年12月发布、并且是
直到今天仍为最新版本、以及一个大约七个月前的版本08.06.00.43、
这是我们在过去半年中积累的经验。
然后、我们将其暴露在各种非常精确定义的网络负载中、并比较其行为
在 MCU +版本之间来回切换。
部分结果对我们来说非常令人惊讶：
(1)
通过版本09.01.00.41、我们发现、在网络流量负载超过以下两项之间的限制时、
67.000和88.000帧/秒(大小为1400字节)的网络通信持续死锁
输出、即 PRU 不再尝试将任何接收到的帧传输到主机处理器。 此影响
可重现性100%。 再也不能持久地减少网络流量负载(低至
零)可以让这种死锁消失。
只有在电路板的硬件复位后、网络通信才会再次正常工作。
对于我们来说，这种行为非常有问题，不符合我们的可用性要求。
与08.06.00.43版本相比、我们从未观察到这样的死锁、即使在较高的流量下也是如此
很棒！
(2)
我们观察了针对因描述符而丢弃的数据包的 PKTDMA-PKTDMA Rx 通道的计数寄存器
饥饿(DMASS0_PKTDMA_0_RCHANRT_dcnt_j)、我们发现、对于版本09.01.00.41、
网络流量限制(超出该限制后开始出现丢包)严重不足
与版本08.06.00.43相比：
对于版本08.06.00.43、我们可以确认、高达大约13.000帧(大小为1400)
可以在不发生任何丢失的情况下每秒接收和传送到主机处理器、而
对于版本09.01.00.41、此限制约为每秒8500帧、即接近40%
更糟糕的是、这不符合我们的要求。
对于我们是否应该把 AM64x 以及
MCU-PLUS-SDK 软件包作为我们已规划应用的适当构建块。
因此、我们希望征求您的意见：
-您是否知道我们发现的版本09.01.00.43的较差属性?
-您能解释一下这些更糟的属性吗?
-您是否正在对当前 MCU-PLUS-SDK 版本进行相应的改进,如果是,
您计划在什么时间范围内发布包含这些改进的下一个版本？
非常感谢您的答复。
此致
S·塞韦鲁斯
