[参考译文] CC3135MOD：使用 CC3135时在 RAW 套接字模式下的长随机发送延迟

您好！

看到流控制达到最小值这一事实意味着 TX 池计数正在下降、因此 NWP 中的数据包被延迟。 always_on 仅在 RX 模式下有用、在 TX 模式下不有用、因此这很清楚您没有看到任何改进的原因。

首先、我将重点讨论 UDP、而不是 TCP 或混合物、因为 TCP 需要来自对等器件的 ACK、在发生这种情况之前、数据包会保留在 TX 队列中、可能会使这种现象变得更糟。 您是否可以确保仅使用 UDP 进行测试？ 使用 UDP 与 TCP 进行测试时、您是否看到不同的行为？

此外、链路质量良好并不一定意味着空气不会拥塞。 您能否仔细检查一下您是否正在处理干净的频道？ 动机是忙通道会使器件延迟其传输、因此也会有效地使问题变得更糟。

最后、如果您更及时地进行空间传输、会怎么样？ 是否有任何改进？ 您使用的数据包大小是多少？

什洛米

尊敬的 Shlomi：

正如我已经提到过的、我将使用 RAW 套接字。 NWP 不知道它是 UDP、TCP 还是其他更高级别的协议。 至少,这应该是这样的。 但是、我同意使用 UDP 可以消除观察此问题时不必要的复杂性。 否、使用 UDP 与 TCP 时的行为不同。

通道的情况。 否、我使用的频道不是纯净的。 如果我转到干净的频道(在2.4GHz 频段很难执行此操作)、问题肯定会得到改善。 另一方面,我没有故意营造一个拥挤的环境。 我只有另外一个 AP 在同一通道上运行、周围什么都没有。 另一个 AP 的信号强度约为-56dBm、接近或低于 NWP 的信号强度。  将 NWP 的信号强度增加到-33dBm (外部天线)并不能改善这种情况。 我将设备转移到了一个完全不同的地方,有不同的接入点,更拥挤,我有类似的结果。 总之、我的环境并不理想、但也并非独一无二。 这与我在客户现场的预期非常接近。

我没有检查较低的传输速率–我需要在应用中每10ms 或更快地发送一次数据包。 数据包大小约为50…200字节、并且是灵活的。 绝对最大值为1514字节。

谢谢。

奥莱克

您好！

无论是否使用 NWP 都没有区别、TX 池是相同的、因此实际获得最小池的事实意味着您没有数据包、因此释放池并恢复正常需要一些时间。

我当时询问空气拥塞的情况、以了解是否是空气导致器件无法发送数据包。

数据包大小不太重要、因为无论大小如何、都会占用来自 TX 池的条目。 因此、每2mSec 帧的最小值意味着每秒500帧。 数据表表示最大理论吞吐量为15Mbps、因此使用1500字节帧意味着在干净环境中每个条码传输1250帧。 500帧仍然较少、但环境可能很繁忙、因此它可能位于边缘。

您使用的 SPI 速率是多少？

您是否有空气嗅探器？

此致、

什洛米

尊敬的 Shlomi：

SPI 频率为20MHz–这是数据表允许的最大频率。 不、我没有空气嗅探器。 如果 NWP 不传输帧、使用监听器的要点是什么–我看到不同 Wi-Fi 接收器的行为完全相同。

问题在于1…3s 及更长的延迟、而不是由于 Wi-Fi 通道拥塞而导致的2….10ms 延迟。

谢谢。

奥莱克

您好！

我之前说的2..10mSec 是指将帧推送到设备的速度。 如果您采用快速方式、流控制机制会停止主机发送更多数据、因此您会延迟。

当您说"不同 Wi-Fi 接收器的相同行为"时、您是指从 CC3135获取传输信号的另一个对等器件？ 如果是、我只想通过空气监听器确保 CC3135不传输或对等器件没有拉取。

如果是由于 CC3135 TX 问题无法传输、我需要考虑调试方法、因为它可能包含在固件中。

此致、

什洛米

尊敬的 Shlomi：

问题不在于、由于当前空调条件下的传入消息率相对较高、某些消息会被推迟发送、甚至最终会丢失。 问题在于 NWP 停止传输几秒来严重中断数据通信。 这是真正的问题。

是的、我确实是指与 CC3153通信的其他对等器件。 它们可以是 AP、STA、P2P 和各种硬件–无关紧要。 器件随机停止从 CC3153接收几秒钟的消息。 然后一切都恢复正常、直到下一个随机停止传输。

是的、我可以从 CC3135固件中看到需要调试。 我建议您自行重现此问题并将其呈现给 TI 开发人员团队以修复错误。

谢谢。

奥莱克

您好！

第一步当然是复制。

我会研究一下、并告诉您。

此致、

什洛米

您好！

我设法构建了与您拥有的设置类似的设置。

我使用 RAW 套接字以及在主机上运行的 lwIP 网络堆栈。

这是一个在 PC 上运行以模拟主机平台的平台、但它应与您拥有的平台类似。

它已经运行了很长时间、UDP 传输的平均值@18Kbps、我看不到传输下降。

我可以在 NWP 日志上看到、如您所见、TX 池数据包确实达到最小值、但没有丢弃。

您能否说明您正在使用的服务包版本？

如果您可以获取 NWP 日志并将其发送、也会很好。  https://www.ti.com/lit/ug/swru455m/swru455m.pdf?ts=1638204986283&ref_url=https%253A%252F%252Fwww.google.com%252F 下的第20.1章介绍了该过程。

只需记住、需要在专用引脚上以二进制模式记录流。

什洛米

尊敬的 Shlomi：

带有 LwIP 的 RAW 套接字正常。 由于 PC 没有外部 SPI 接口、因此使用 PC 可能会成为一个问题。 您需要具有 SPI 接口的外设卡来连接到 NWP。 该卡将有其自身的缓冲对 PC 不可见。

UDP 传输无问题。 我真的不关心比特率-您需要发送数据包、例如50字节长的数据包(仅限于特定情况)、每10ms 或更短的时间发送一次、以重现问题。

问题在于传输的随机延迟、有时超过3秒。 丢包(我们讨论的是丢包、而不是连接丢失)是长时间延迟的结果、而不是单独的问题。 由于较大的传输缓冲区可在传输延迟期间容纳所有消息、因此可能不会出现任何压降。 是否发现传输存在长时间的随机延迟？

可以看到 TX 池数据包计数器达到其最小值、这一点很好。 这是您应该看到延迟的时间点，因为10ms 内的下一个数据包将导致 sl_Send()锁定并等待至少一个数据包被发送，TX 池数据包计数器高于其最小值。 您只需要测量该延迟。

我使用的是最新的 NWP 服务包：NWP 4.13.0.2 MAC 3.7.0.1 PHY 3.1.0.26。

我没有资源来获取 NWP 日志。

谢谢。
奥莱克

Olek,

我是通过 SPI 从 PC 连接,并发送比你说的更频繁,因为我达到高 TP 和 TX 池下降到最低。 我仍然看不到您所讨论的问题。 到主机的流控制清晰且符合预期、但由于内部池始终装满至少一个数据包、因此对空中的流控制没有瓶颈。 另外、UDP 是测试的方法、而不是 TCP、因为 TCP 取决于 TCP ACK、如果另一方不将其拉至应用层、则在 NWP 需要保留数据包以进行重新传输时可能会发生这种行为。

如果没有获取 NWP 日志并查看内幕的选项、我就无法提供任何内容。 为什么很难获得 NWP 日志？

什洛米

尊敬的 Shlomi：

您能否告诉我您的实验中消息速率 FlowContCB.TxPoolCnt 值下降到 FLOAD_CONT_MIN？ 我看到每条消息大约为2ms。 我看到由于瓶颈导致传输延迟时；NWP TXD 缓冲区中没有更多空间、但新消息继续出现。 此时、我看到 NWP 传输的消息突发、假设十个左右的消息一个接一个传输(清除内部 NWP 缓冲区)、然后在不传输任何内容时延迟10...20ms。 请记住、您需要在同一信道上至少有一个具有相同或略低于 NWP 功率的 Wi-Fi 接入点、才能创建真实的工作环境。

经过上述瓶颈实验后、当您得到最大传输速率时、将每条消息的传输速率降至10ms (消息大小~50字节)。 您应该会看到抖动为2-3ms 的消息传输十分平滑。 这是很好的,它应该是这样的。 然而、您还会不时看到10...100ms 的延迟、并且您将看到随机的长时间延迟、有时会在5...20分钟内持续超过3s。 这是您尝试重现的问题。

请不要再次引入 TCP 参数-我同意使用 UDP 来重现问题。

据我所知、我们是在调试您的 NWP、而不是器件。 策略是在设置上重现我的问题、这非常容易重现、然后您可以收集调试 NWP 所需的任何日志。

谢谢。
奥莱克

Olek,

对我来说<2mSec 会触发它。 我所做的是循环传输一系列帧、这些帧将导致 TX 池触发流控制(数据包之间的延迟<2mSec)、然后增加延迟、从而使其始终无法达到最小流控制(我尝试了从2mSec 到20mSec 的各种延迟)。 我还使用50字节的帧。

我已经用一个空气嗅探器和一个 NWP 日志运行了几个小时、一切看起来都正常、所以很难知道您为什么看到它。 我想您更困扰于在几秒钟内的大量延迟,而不是从10..100mSec 延迟,对吗?

我会试着想一种方法来强调它。

什洛米

尊敬的 Shlomi：

非常感谢您研究此问题。 是的、我的主要问题是延迟时间很长。 较短的延迟可由内部 NWP TXD 缓冲器处理(足够大)、并且由于无线电通道的不可预测性质、较短的延迟将始终存在。 但 NWP 无法处理持续数秒的长延迟。

我注意到、当存在无线电干扰时、一个或两个 AP 也使用与 NWP 相同的信道时、会出现较长的延迟。 我附上了两个图表。 第一个是在干净通道上接收到消息之间的延迟(消息以10ms 的速率发送)。 最长延迟在第14分钟为~31ms–绝对没有问题。 第二幅图显示了当另一个 AP 在同一通道上工作时的相同延迟。 您可以看到第2分钟的延迟为~1.3s。

我希望您的设置会出现类似的行为。

谢谢。

奥莱克

https://1drv.ms/i/s!AnPbPYflhT1RvSKAEJPJwRwsy6VI?e=Dff6gm

https://1drv.ms/i/s!AnPbPYflhT1RvSEPmP473jzV71Wa?e=mm56pa

您好、Olek：

对我来说、我用空气嗅探器捕获、并探测延迟。 即使我在同一通道上添加了另一个 AP 并向空中加载了并行数据流、我也看不到高延迟。

那么、您这边的问题是延迟来自哪里。 可能是由于某种原因使器件推迟、但没有证据表明这一点。 也可能是因为空气看起来很忙/很拥挤、但我不知道它有多忙、因为你没有空气嗅探器。 链路有两侧、即从站点到 AP、以及从 AP 到另一个对等器件。 AP 会重复数据包(TO-DS 和 from-DS)、因此还需要知道其中一方是否因某种原因而遭受痛苦。 也可能是对等器件本身。

如果没有至少一个空气嗅探器,就很难分辨,所以我不知道我们还能做些什么,因为我无法重现。

此致、

什洛米

尊敬的 Shlomi：

我的实验中没有额外的 AP<->站点连接。 我使用了两个 NWPS、一个在 AP 模式下、另一个在站点模式下收集我在此处发布的数据。 此设置在基站侧的固件中有准确的时间戳。 然后、我将工作站模式下的 NWP 替换为 PC、并使用我的 PC 软件在 AP 模式下捕获 NWP 发送的数据。 PC 上的时间戳不太准确、但仍然可以接受、我仍然看到问题。 此外、我还尝试了 AP 和基站模式以及两者之间的路由器等的不同组合。

我对 Wi-Fi 协议不是很熟悉。 AP 是否可以传输数据包、您可以使用嗅探器看到该数据包、但站点不处理该数据包？ 站点端是否有流控制机制可以请求重传、而 AP 端不会进行重传？ 我在此推测、是为了合理解释您没有看到监听器出现延迟的原因。 记住、我并不真正关心无线网络信息的传输。 我需要在站点端接收 IP 消息而不会出现长时间延迟。

谢谢。

奥莱克

您好、Olek：

你让我对最后一条消息感到困惑。 发送的 Simplelink 是否处于 AP 角色？ 您的最终产品是否应担任 AP 角色？ 我的实验是站角色、因为这是我的理解。 不确定这是否会变化太大、仅为了与两种设置保持一致。

对于您的问题、在 Wi-Fi 上、如果发送端未从另一端(在 Wi-Fi 层)获得确认、则会重新传输。 重新传输数据量以及速率回退的工作方式的实现不在该规范范围内、每个供应商可能会以不同的方式实现它。 Wi-Fi 数据包得到确认后、会上传到网络堆栈的处理中、并等待主机将其拉取。 如果站点使用 AP 实现节能、则可能有高达信标间隔的延迟。

此致、

什洛米

尊敬的 Shlomi：

任何模式下都可能出现此问题：基站、AP、P2P。 我发布了 AP 模式下 NWP 与站点模式下另一 NWP 通信的数据。

正如我所预期的、由于 Wi-Fi 消息确认机制、监听器在此处不适用。 您需要在 IP 级别、而不是 Wi-Fi 级别上看到问题。

如果您坚持认为无法看到问题、请确认您在 NWP (任何模式)与 IP 级别上的其他 Wi-Fi 节点之间进行通信、每条消息的传输速率为10ms、并且在同一信道上存在其他设备时不会出现长时间的随机延迟。 IP 级别是指您使用 sl_Send ()发送消息,并在其他对等 Wi-Fi 设备上使用套接字接收功能来接收消息。

谢谢。

奥莱克

您好、Olek：

我不会在任何层、Wi-Fi 或 IP 中看到问题。  

我不理解您声称由于  Wi-Fi 消息确认机制、监听器不适用。 这话什么意思？ 嗅探器可能会对您所看到的内容有所了解、并解释发生这些滴落的原因。  

您是否尝试过使用外部 AP (不是 Simplelink)？

什洛米

尊敬的 Shlomi：

如果您在 IP 级别上看不到该问题、很遗憾、我们已经到了尽头。

该监听器对于调试 Wi-Fi 层非常有用。 如果您在 IP 级别上看不到该问题、则表明 Wi-Fi 器件正常。

是的、当然可以。 阅读我以前的文章。 我尝试了一切。 我尝试使用 NWP 在站模式下通过 Wi-Fi 路由器将其连接到 PC、结果相同。 如前所述、如果您在 NWP (具体而言、在 AP 模式下)与 IP 级别的其他 Wi-Fi 节点(在站点模式下)之间进行通信、每条消息的传输速率为10ms、而在同一信道上存在其他器件时、不会出现长时间的随机延迟、 则无法重现问题。

谢谢。
奥莱克

您好、Olek：

我在 Wi-Fi 或 IP 上都看不到它。

请注意、Wi-Fi 层上的问题可能会导致 IP 层上的问题、但我同意如果 Wi-Fi 层运行正常、您仍然会在 IP 层上遇到问题。 我想要一个空气监听器、只是为了确保不会在 Wi-Fi 层遇到任何问题。

是的、似乎我无法不幸地重现它。

您是否准确地执行了所有步骤并禁用了内部筛选器 和网络应用程序？

什洛米

尊敬的 Shlomi：

我完全按照用户指南(swru455m.pdf)中的所有步骤进行了操作。 内部过滤器和网络应用程序被禁用。

与用户指南的唯一区别是、我首先使用
sl_NetAppGet (sl_NETAPP_STATUS、sl_NETAPP_STATUS_ACTIVE_APP、&pOptionLen、(_u8 *)&AppBitMap)；
然后使用
if (AppBitMap) sl_NetAppStop (AppBitMap)；

我认为它没有任何区别。

谢谢。
奥莱克

谢谢、您是对的。 它没有区别。

我只想确保内部 net 应用程序不占线。