ATWINC15x0 Wi-Fi模块吞吐量实测：iPerf TCP/UDP性能评估与优化

1. 项目概述：为什么我们需要关注Wi-Fi模块的吞吐量？

最近在调试一个基于ATWINC15x0系列Wi-Fi模块的物联网设备，遇到了一个典型问题：设备上报数据时快时慢，偶尔还会丢包。排查了一圈硬件和软件，最后怀疑是Wi-Fi模块本身的网络性能存在瓶颈。于是，我决定搭建一个标准的测试环境，用iPerf这个网络性能测试的“瑞士军刀”，对ATWINC15x0模块的TCP和UDP吞吐量进行一次彻底的摸底评估。

对于嵌入式开发者而言，Wi-Fi模块的吞吐量绝不是一个纸面参数。它直接决定了你的设备数据传输上限、响应延迟和整体用户体验。比如，一个智能摄像头，如果Wi-Fi吞吐量不足，高清视频流就会卡顿；一个数据采集终端，如果上传速率不稳定，就可能丢失关键数据。ATWINC15x0作为一款在成本、功耗和集成度上取得平衡的经典模块，其实际性能表现如何，尤其是在不同网络协议（TCP/UDP）下的差异，是项目选型和后期优化的重要依据。这次测试的目的，就是抛开数据手册的理想值，在真实的网络环境中，获取可复现、可比较的性能数据，为后续的协议选择、缓冲区设置和网络重传策略提供决策支持。

2. 测试环境搭建与核心工具选型

2.1 硬件平台与网络拓扑设计

测试的核心是建立一个可控的“客户端-服务器”模型。我的配置如下：

• 被测设备（Client）：一块搭载了ATWINC15x0模块（具体型号为ATWINC1510）的定制开发板。该模块通过SPI接口与主控MCU（一颗常见的ARM Cortex-M4芯片）通信。MCU上运行着基于FreeRTOS的嵌入式软件，并集成了模块厂商提供的Socket驱动库。
• 服务器端（Server）：一台运行Windows 10的笔记本电脑，配备千兆有线网卡。选择有线连接是为了消除服务器端无线网络可能带来的性能波动和干扰，确保测试瓶颈集中在被测Wi-Fi模块上。
• 网络设备：一台支持802.11n/ac的家用无线路由器，作为接入点（AP）。测试时，将路由器的2.4GHz频段设置为单一信道（如信道6），并关闭诸如“频段导航”、“WMM”等可能影响测试结果的高级功能，创造一个相对干净的环境。

整个拓扑非常简单：ATWINC15x0模块作为客户端，通过Wi-Fi连接到路由器；服务器通过网线直连到路由器的LAN口。这样，数据流就是从模块无线发出，经路由器有线转发到服务器。

注意：务必确保测试环境内没有其他大流量设备占用Wi-Fi信道。最好在深夜或独立房间进行，并将路由器的加密方式暂时改为WPA2-PSK AES，避免更复杂的加密算法（如WPA3）在低性能MCU上带来额外开销。

2.2 软件工具：iPerf 2与iPerf 3的抉择

iPerf是本次测试的灵魂。目前主流有两个版本：iPerf 2 和 iPerf 3。它们并不完全兼容，需要根据场景选择。

• iPerf 2 (2.1.6版本)：这是经典且广泛使用的版本。它的一个巨大优势是协议兼容性好，其服务器端可以接受来自iPerf 2或iPerf 3客户端的连接。对于嵌入式场景，很多现成的Socket库示例代码都是基于iPerf 2的协议进行通信。此外，它的输出信息非常详尽，对于深度分析很有帮助。
• iPerf 3：这是一个重写版本，代码更现代，旨在提供更简单的API和更精确的测量。但它与iPerf 2的协议不兼容，意味着iPerf 3的服务器不能接受iPerf 2客户端的连接。

考虑到ATWINC15x0的Socket库可能更贴近传统实现，且为了获得最广泛的对比参照，我最终选择了iPerf 2.1.6作为服务器端工具。在Windows笔记本上，直接从官网下载编译好的二进制文件，打开命令行即可运行。

2.3 嵌入式端的准备：移植iPerf客户端逻辑

ATWINC15x0模块本身不运行iPerf，它只是一个网络接口。真正的iPerf客户端逻辑需要我们在主控MCU上实现。这并不意味着要移植整个iPerf软件，而是实现其测试协议。

iPerf的基本工作原理是：客户端与服务器建立TCP连接后，会先进行一些控制信息的交换（如测试参数），然后根据指定的测试模式（TCP或UDP），在规定的测试时间内，尽可能快地向服务器发送数据包。服务器端负责接收、统计并最终汇总报告吞吐量、丢包率等信息。

因此，我在MCU的应用程序中，创建了两个任务：

1. 网络管理任务：负责驱动ATWINC15x0模块，执行扫描、连接AP、获取IP地址等。
2. iPerf测试任务：在连接成功后，创建一个Socket，连接到服务器端的iPerf服务端口（默认5201），然后按照iPerf协议格式，先发送测试配置，再进入疯狂发送数据的数据传输循环。对于UDP测试，还需要在数据包中填充时间戳和序列号，以便服务器计算抖动和丢包。

3. TCP与UDP性能测试实战与数据分析

3.1 TCP吞吐量测试：追求稳定的最大带宽

TCP是面向连接的可靠传输协议，其吞吐量测试反映的是在保证数据正确、有序到达的前提下，链路所能承载的最大稳定数据传输速率。

服务器端启动命令：

iperf -s -i 1

-s表示以服务器模式运行，-i 1表示每秒输出一次中间报告。

客户端（MCU程序）行为：建立TCP连接后，持续向服务器发送数据，默认测试时间通常为10秒。我调整了发送缓冲区大小，尝试了从1KB到16KB的不同设置，观察其对性能的影响。

一次典型的测试结果输出（服务器端）：

... [ 3] local 192.168.1.100 port 5201 connected with 192.168.2.101 port 49152 [ ID] Interval Transfer Bandwidth [ 3] 0.0- 1.0 sec 512 KBytes 4.19 Mbits/sec [ 3] 1.0- 2.0 sec 640 KBytes 5.24 Mbits/sec [ 3] 2.0- 3.0 sec 640 KBytes 5.24 Mbits/sec [ 3] 3.0- 4.0 sec 640 KBytes 5.24 Mbits/sec [ 3] 4.0- 5.0 sec 640 KBytes 5.24 Mbits/sec [ 3] 5.0- 6.0 sec 640 KBytes 5.24 Mbits/sec [ 3] 6.0- 7.0 sec 640 KBytes 5.24 Mbits/sec [ 3] 7.0- 8.0 sec 640 KBytes 5.24 Mbits/sec [ 3] 8.0- 9.0 sec 640 KBytes 5.24 Mbits/sec [ 3] 9.0-10.0 sec 640 KBytes 5.24 Mbits/sec [ 3] 0.0-10.0 sec 6.25 MBytes 5.24 Mbits/sec

数据分析与解读：

1. 连接建立：可以看到客户端（ATWINC15x0）的IP是192.168.2.101，通过端口49152连接到服务器。
2. 带宽稳定性：初始第一秒速率较低，这通常是TCP慢启动过程。之后稳定在5.24 Mbits/sec左右。这个数值就是ATWINC15x0在该测试环境下的TCP吞吐量。
3. 影响因素：
   • SPI时钟频率：ATWINC15x0与MCU通过SPI通信，提高SPI时钟能显著提升数据交换速度。我测试了从10MHz到20MHz的变化，吞吐量有近30%的提升。
   • TCP窗口大小：嵌入式端的TCP发送缓冲区大小是关键。缓冲区太小，发送线程很快就会因缓冲区满而阻塞；太大则会占用过多内存。经过反复测试，对于5Mbps左右的流量，设置一个8KB的缓冲区是比较均衡的选择。
   • Wi-Fi信号强度（RSSI）：这是最重要的外部因素。当我把开发板移到距离路由器更近、信号强度（RSSI）从-70dBm提升到-50dBm时，吞吐量从5Mbps左右提升到了接近7Mbps。

实操心得：测试TCP吞吐量时，不要只看最终平均值。观察每秒的间隔报告，如果曲线像锯齿一样剧烈波动，说明网络不稳定或MCU处理有瓶颈。一个健康的TCP测试结果，其带宽曲线在稳定后应该是一条平坦的直线。

3.2 UDP吞吐量测试：探索极限与评估抖动

UDP是无连接的协议，不保证可靠性和顺序。测试UDP吞吐量，我们关注的是链路在不过载的情况下，能转发的最大数据包速率，同时会密切关注丢包率和抖动。

服务器端启动命令：

iperf -s -i 1 -u

-u表示使用UDP协议。

客户端（MCU程序）行为：需要指定一个目标带宽。例如，我们想测试在5Mbps发送速率下的表现。程序会计算出发送间隔，并严格按照这个间隔发送UDP数据包。每个数据包内会包含序列号和时间戳。

一次典型的UDP测试结果输出（服务器端）：

... [ 3] local 192.168.1.100 port 5201 connected with 192.168.2.101 port 49153 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 3] 0.0- 1.0 sec 640 KBytes 5.24 Mbits/sec 0.123 ms 0/80 (0%) [ 3] 1.0- 2.0 sec 640 KBytes 5.24 Mbits/sec 0.098 ms 0/80 (0%) [ 3] 2.0- 3.0 sec 640 KBytes 5.24 Mbits/sec 0.215 ms 1/80 (1.2%) [ 3] 3.0- 4.0 sec 640 KBytes 5.24 Mbits/sec 0.087 ms 0/80 (0%) ... [ 3] 0.0-10.0 sec 6.25 MBytes 5.24 Mbits/sec 0.112 ms 3/800 (0.38%)

数据分析与解读：

1. 带宽：成功达到了预设的5.24 Mbits/sec发送速率。
2. 抖动（Jitter）：这是UDP测试的核心指标之一，表示数据包延迟的变化。本例中平均0.112ms的抖动非常低，说明网络非常稳定。对于音视频流，抖动通常需要控制在30ms以内。
3. 丢包率：10秒内总共发送800个数据包，丢失3个，丢包率为0.38%。在Wi-Fi环境中，少量的丢包是正常的，尤其是当测试速率接近物理极限时。

压力测试：接下来，我逐步提高客户端的发送带宽，从5Mbps增加到8Mbps，再到10Mbps。观察结果变化：

这个测试清晰地告诉我们，在这个特定环境下，ATWINC15x0模块的UDP有效吞吐量极限大约在7.6-7.8 Mbps。超过这个值，网络就会成为瓶颈，导致大量丢包。

注意事项：UDP测试时，客户端的发送速率是“试图达到”的速率。如果设置得过高，远超过物理极限，你会看到接近100%的丢包，而实际接收带宽很低。正确的做法是逐步增加带宽，找到丢包率开始显著上升（例如>1%）的那个拐点，拐点前的带宽就是可用的UDP吞吐量。

4. 性能瓶颈分析与深度优化探讨

通过上述测试，我们得到了一些原始数据。但工程师的思维不能止步于此，必须追问：为什么是这个数字？瓶颈在哪里？

4.1 瓶颈定位：是Wi-Fi射频，还是系统总线？

ATWINC15x0模块的理论物理层速率（PHY Rate）在802.11n模式下可以达到72Mbps。但我们测得的TCP/UDP吞吐量仅在5-8Mbps量级。这巨大的差距来自哪里？

1. 协议开销：Wi-Fi传输有大量的帧头、确认机制、冲突避免开销。TCP/IP协议栈本身也有包头。实际可用的应用层数据吞吐量通常只有物理层速率的50%甚至更低。
2. SPI总线瓶颈：这是非常关键的一点。应用层数据需要经过MCU处理，再通过SPI接口发给Wi-Fi模块。SPI是全双工，但实际数据流是主从式。SPI的时钟频率、每次传输的数据块大小、以及MCU处理SPI中断的效率，共同决定了这条数据通道的宽度。我通过逻辑分析仪抓取SPI波形，发现在高负载时，SPI线上存在明显的空闲时间，这说明MCU没有及时填充数据，可能是在进行内存拷贝或协议处理。
3. MCU处理能力：运行TCP/IP协议栈（即使是轻量级的LwIP）、处理Socket调用、准备发送数据，这些都需要CPU时间。如果MCU主频较低，或任务调度不当，就可能无法“喂饱”Wi-Fi模块。

4.2 针对性优化实践

基于以上分析，我尝试了以下优化，并观察了对吞吐量的影响：

• 优化SPI驱动：将SPI传输模式从轮询改为DMA（直接内存访问）。这是提升最大的一步。DMA让CPU从繁重的数据搬运工作中解放出来。优化后，TCP吞吐量从5.24Mbps提升到了6.8Mbps。
• 调整TCP窗口/缓冲区：根据“带宽延迟积”粗略估算，适当增大了TCP发送窗口和Socket缓冲区，减少了因等待确认而导致的发送暂停。
• 优化应用层数据打包：避免频繁发送小包。例如，将传感器数据在内存中累积到一定大小（如512字节）再一次性发送，减少了协议头开销和系统调用次数。
• Wi-Fi参数微调：在路由器后台，将Wi-Fi模式固定为802.11n only，带宽固定为20MHz，并选择干扰最小的信道。这些设置牺牲了部分兼容性和理论速率上限，但换来了更稳定、可预测的连接，实测吞吐量方差变小了。

经过这几轮优化，最终在信号良好的情况下，ATWINC1510模块的TCP稳定吞吐量达到了约7.5 Mbps，UDP极限吞吐量达到了约9 Mbps。这个性能对于大多数传感器数据上报、中等码率音频传输等物联网应用已经足够。

5. 常见问题排查与调试技巧实录

在实际测试中，你肯定会遇到各种意想不到的问题。下面是我踩过的一些坑和解决方法：

问题1：iPerf服务器端启动后，客户端连接被拒绝（Connection refused）。

• 排查：首先在服务器电脑上运行netstat -an | findstr 5201，检查5201端口是否真的在监听。很可能是因为Windows防火墙阻止了iPerf。
• 解决：在Windows防火墙中为iperf.exe添加入站规则，允许其通过公用和专用网络。更简单粗暴的测试方法是暂时关闭防火墙（测试完记得打开）。

问题2：测试带宽结果低得离谱，只有几十Kbps。

• 排查：
  1. 检查Wi-Fi连接速率：在ATWINC15x0驱动中，一般有API可以读取当前的“连接速率”（Link Rate）。如果这个值本身就很低（比如只有1Mbps），那应用层吞吐量肯定上不去。这通常是信号太差导致的。
  2. 检查MCU调试输出：在发送数据的循环里加打印，看是不是每发送一次就调用了printf这类超级耗时的函数？它们会严重拖慢主循环。
  3. 用Ping测试基础延迟：从服务器Ping模块的IP地址，看延迟是否稳定在几毫秒。如果延迟几百毫秒甚至丢包，说明网络连接基础就有问题。

问题3：UDP测试丢包率异常高（>10%）。

• 排查：
  1. 确认发送速率是否过高：这是最常见原因。先尝试一个很低的速率（如1Mbps），如果丢包率降为0，说明就是发送太快了。
  2. 检查服务器端性能：你的服务器电脑是否同时运行着大量程序？可以打开任务管理器，看CPU和网络利用率。尝试关闭不必要的软件。
  3. 检查路由器性能：老旧或低端路由器可能无法处理高速率的数据流。有条件可以换一个路由器试试。

问题4：测试结果波动很大，每次运行差异明显。

• 解决：这是无线测试的常态。唯一的方法是多次测试取平均。我通常的做法是，在固定位置和配置下，连续运行10次测试，去掉最高和最低值，然后取平均。这样得到的数据才有参考价值。同时，记录下每次测试时的Wi-Fi信号强度（RSSI），有助于分析波动是否与信号变化相关。

一个实用的调试技巧：分阶段测试。不要一开始就让MCU跑完整的iPerf逻辑。先写一个最简单的测试程序：创建一个UDP Socket，然后以固定间隔（比如每秒一次）发送一个包含递增数字的小包到服务器的一个简单UDP回显服务。确保这个基础通信是稳定、无误的。然后再逐步增加数据量、缩短间隔，最后才替换成完整的iPerf协议逻辑。这种“由简入繁”的方法能帮你快速定位问题是在网络连接、基础Socket操作，还是在复杂的协议实现上。

通过这一整套从环境搭建、工具选型、测试执行到数据分析、瓶颈定位和问题排查的流程，我们不仅得到了一组关于ATWINC15x0模块的性能数据，更重要的是掌握了一套评估嵌入式Wi-Fi性能的方法论。这套方法可以复用到任何类似的无线模块上，帮助你在产品开发早期就认清网络能力的边界，避免后期出现难以调优的性能问题。