Riot: IEEE802.15.4：HW Auto ACK 被认为是有害的

在大多数情况下，这种做法可能是有害的。

实际上，这多久会造成实际伤害？ 有多少百分比的消息在被 MCU 实际丢弃时得到确认？

接收时无线电切换到 TX 模式 (#11256)

这种情况对于具有共享接收/发送缓冲区的无线电来说是独一无二的，对吧？ 所以只影响 at86rf2xx 类设备

这会产生奇怪的行为，......

您是否有一些导致问题的示例？

因此，我建议将 Auto ACK 保留为可选，并在软件中实现 ACK 响应

你对这方面的影响有一些数字吗？ 闪存大小/RAM 使用情况，还有功耗，因为 MCU 必须唤醒更长的时间。 此外，在帧接收和确认超时之间有多少时间，如果无线电通过 SPI 连接，在软件中处理 ACK 是否现实？

除了拥有更可靠的 L2

我对这个说法有点怀疑（如果我的评论还不清楚的话），处理 L2 ack 是一个软实时案例（错过最后期限会降低服务质量）并且在软件中处理它们对RIOT 的实时行为。

我不介意软件 L2 确认它是否是某些特定 MAC 层的硬性要求，但是这里的描述中没有提到这一点。

嗨@bergzand

实际上，这多久会造成实际伤害？ 有多少百分比的消息在被 MCU 实际丢弃时得到确认？

对于上层来说，这没什么大不了的（考虑到它们通常是尽力而为）。
但是，一些 MAC 和子 MAC 层（OpenThread、TSCH）使用 ACK 来更新邻居信息。

这种情况对于具有共享接收/发送缓冲区的无线电来说是独一无二的，对吧？ 所以只影响 at86rf2xx 类设备

真的。 我只是指出可能发生这种情况的场景。

您是否有一些导致问题的示例？

向 MAC 层的用户提供错误的信息（例如 Mesh 链路建立）可能会影响链路质量。 我知道虽然我们在 RIOT 中还没有这样的东西（并且使用它的堆栈已经实现了该功能）。

你对这方面的影响有一些数字吗？ 闪存大小/RAM 使用情况，还有功耗，因为 MCU 必须唤醒更长的时间。 此外，在帧接收和确认超时之间有多少时间，如果无线电通过 SPI 连接，在软件中处理 ACK 是否现实？

不幸的是没有。 由于尚未实施，因此我没有可比较的数字。 我只有一些带有自动 ACK 的测试分支，但我没有进行更深入的测试。

我对这个说法有点怀疑（如果我的评论还不清楚的话），处理 L2 ack 是一个软实时案例（错过最后期限会降低服务质量）并且在软件中处理它们对RIOT 的实时行为。

来自 Tiny OS 的一些信息表明，软件 ACK 的下降率往往更高（https://vs-git.informatik.uni-kl.de/engel/tinyos/blob/020c6a6d8cc542bf58ca6afb8b1bf24efbe381de/doc/txt/tep126.txt），但至少没有误报。
AFAIK IEEE802.15.4 没有谈论硬约束（仅关于超时值）。 如果 ACK 数据包没有及时传递，则认为它丢失了。 但如前所述，我不知道操作系统在软件 ACK 方面的表现如何。 有一些基准会很有趣

我不介意软件 L2 确认它是否是某些特定 MAC 层的硬性要求，但是这里的描述中没有提到这一点。

无论如何，我们都需要为不支持自动 ACK 的无线电和硬件加速器中不可用的功能实现软件 ACK（老实说，我不知道支持增强型 ACK 的无线电）。
问题是，我们希望这对于我们的默认配置是可选的还是强制的？ 如前所述，这个想法不是要删除 Auto ACK 支持，而是要更好地支持 L2。 如果我们愿意，我们仍然可以启用 Auto ACK（这就是我建议在 https://github.com/RIOT-OS/RIOT/pull/11473 中添加无线电上限的原因）

也许我错了，但解决方案似乎很简单：

• 我们实现了一个（与硬件无关的）ARQ -> 无论讨论如何，我们都想要它。
• 我们比较了硬件和软件实现的性能（和互操作性）。
• 我们希望有一个特定于平台的默认设置，它不会阻止编译另一个。

作为一个侧面节点：我们从未遇到过@jia200x强调的问题，这可能与 RIOT 中无线电顶部缺少 MAC 层有关。 此外，对于低功率有损无线电，我们无论如何都可以容忍一定的损失。

6TiSCH 的软件 ACK 有多重要？ IIRC，OpenWSN 部分使用软件 ACK 来跟踪邻居之间的链路质量。

6TiSCH 的软件 ACK 有多重要？ IIRC，OpenWSN 部分使用软件 ACK 来跟踪邻居之间的链路质量。

6TiSCH 不反对硬件 ACK，但需要增强型 ACK 来传递时序信息。 在 OpenWSN 中，这由 pkg 本身处理。

*我所知道的硬件不支持增强型 ACK。

此外，在某些情况下，硬件确认能力的问题在于它完全负责该机制，而不必暴露相关信息，例如收到的 ACK 或重试次数。 使用 6TiSCH，您可能会在需要此类信息的其他单元中重新传输帧。 因此，OpenWSN 基于有限的无线电设备功能集并在软件中实现所有其他 MAC 组件。

此问题已自动标记为过时，因为它最近没有活动。 如果没有进一步的活动发生，它将被关闭。 如果您希望我忽略此问题，请使用“状态：不要过时”标签对其进行标记。 感谢你的贡献。