This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] CC3220SF-LAUNCHXL:发送功能时间长、多个丢包丢失

Guru**** 2581345 points


请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/968546/cc3220sf-launchxl-long-time-in-send-function-multiple-lost-packets

器件型号:CC3220SF-LAUNCHXL

您好!

我在 CCS 中使用 TCP 回显示例。 我注意到将数据从 CC3220流式传输到 PC 时出现的问题、其中多个(5-15)数据包将连续重新传输丢失。 这种情况与 SEND 函数的返回时间很长(1 - 10秒)相同。 通常、即使存在快速重传、发送函数也会在2ms 内返回。 我正在流式传输的数据以恒定速率传入、因此当发送功能停止时、我会丢失数据。

以下是发生这种情况时 TCP 吞吐量的图像:

我已经在同一网络上同时运行程序的多个 LaunchPad 上测试了此问题、以查看问题是否随着流量的增加而增加。 该问题在添加 LaunchPad 时以相同的频率出现(大约每20分钟一次)、并且数据速率足够低(每个 LaunchPad~0.2 Mbps)、我不认为网络拥塞是潜在问题。 当多个 LaunchPad 运行程序时、丢弃的数据包会同时发生。

您对该问题可能发生的原因有什么了解吗? 或者、在需要很长时间才能继续缓冲传入的数据并尝试重新发送时、是否有办法从发送函数返回?

谢谢、

Michelle

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    抱歉、这张照片看起来没有贴附在帖子中。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Michelle:

    您用于 TCP 流量的数据包大小是多少? 如果 sl_Send 需要几秒钟的时间才能返回、则很可能意味着 CC3220已耗尽其 TCP 缓冲区、或者远程端已退出缓冲区。

    您是否能够捕获空气嗅探器? 这将有助于我们了解导致 CC3220重新传输的原因。

    此致、

    Michael

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Michael、

     

    感谢您的回答!

     

    我正在发送1400字节的数据包、我选择这种数据包是因为它安全地低于以太网的 MTU。 我还在接收数据的应用程序上进行了错误检查、以在接收缓冲区已满时通知我、并且从未就此问题引发错误。

     

    我在 Wireshark 中捕获了网络流量以观察该问题、但我没有注意到网络上任何其他流量会减慢传输速度。 在问题发生之前不久会出现一些 LLDP 多播消息、但这些消息每30秒显示一次、因此它们似乎不太可能导致问题。

     

    我已附加了一个.pcap 文件供您查看。 错误从数据包48393开始。 此捕获包括2个 CC3220 (10.156.1.100和10.156.1.102)发送到桌面(10.156.1.144)。 桌面通过以太网连接到网络。

     

    e2e.ti.com/.../retransmission_5F00_errs_5F00_01_5F00_04_5F00_21.zip

    我已将我使用的网络放置在与家庭 WiFi 不同的信道上、以避免信道干扰、但信道上有一些无法控制的邻近网络。 这些网络上的流量是否可能导致我的数据包丢失?

     

    谢谢、

    Michelle

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Michelle:

    您的 MTU 应该可以正常工作、如果您正在检查接收端的缓冲区、我们可以将其作为问题的来源来消除。 您的 Wireshark 日志显示了重新传输、但它们对可能发生此问题的原因没有任何其他见解。

    您是否每20分钟观察一次该问题而不会失败、或者数据包有时会更快/更晚地丢失?

    此外、当您的 CC3220器件连接到不同的 AP 时、是否会出现相同的问题? 过去、这种周期性连接错误被发现是特定 AP 模型的互操作性问题。 但是、较新的 CC32xx 服务栈应修复此问题。 您是否确保您的 CC3220上运行了最新的 CC32xx 服务接收器?

    此致、

    Michael

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Michael、

    在长时间流式传输数据后、我注意到错误恰好每小时发生一次。 我最初以为每20分钟~μ s、因为我通常在开始流式传输后看到第一个错误大约20-30分钟、但现在我观察到、如果我让程序继续运行、我将在第一次错误发生后恰好1小时内收到另一个错误。 我认为可能是我的 DHCP 租用时间导致了这种情况、但它设置为24小时、因此可能不会。

    我尝试使用不同的路由器和不同的计算机。 这两种情况下均存在错误。

    对于服务包、我认为它是最新的? 我使用的是 simplelink SDK 4.30.00.06和 service pack 3.17.0.4。 我认为这是几个月前更新过的。

    另一个需要说明的问题是、我在一个环境中运行此测试、我确信没有干扰流量、但我仍然看到问题。 CC3220上是否有某种中断或每小时复位一次的中断会导致此问题?

    谢谢、

    Michelle

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Michelle:

    有趣的是、误差始终如一地每小时发生一次。

    您使用的 SDK 和服务包是最新的、因此这不是问题的根源。

    再看一下 Wireshark 日志、似乎当重新传输发生时、PC 上运行的服务器报告其 TCP 窗口为0、这意味着其接收缓冲区已满。 因此、我怀疑问题与您使用的服务器软件有关。 此外、您的 PC 上的一个过程可能每小时执行一些网络任务、该过程会暂时加载 PC 的网络接口。

    如果您使用不同的服务器设置,或使用 iperf 等工具测试 TCP 功能,是否看到相同的错误?

    此致、

    Michael