https://blog.csdn.net/tankai19880619/article/details/91966964
iperf -c ipaddress_server -t 60 -i 1 -w 2M
iperf -s -i 1 -w 2M
-w window 对于TCP方式，此设置为TCP窗口大小。对于UDP方式，此设置为接受UDP数据包的缓冲区大小，限制可以接受数据包的最大值
-u udp -b UDP模式使用的带宽，比如-b 100M
-p port
上行（PC作Server，手机作Client）
一、手机吞吐量测试方法
准备工具：手机侧安装Magic Iperf软件；PC侧安装iperf.exe
1.上行吞吐量测试方法
手机作为client端，PC为server端
2.下行吞吐量测试方法
手机作为server端，PC作为client端
TCP的只需要去掉-u参数即可：-i表示几秒回显一次，-t表示测试时常，-w表示缓存区大小
注意，UDP测试方法见下图：
二、影响wifi吞吐量的因素
首先，吞吐量属于极限测试、即检验手机在极限状态下的最大网络容量。故，最好选择近距离屏蔽房环境测试、以排除干扰。
1.软件因素
后台扫描
蓝牙共存
EDCA竞争，RTS、CTS帧等
息屏省电模式
2.硬件
发射端：发射功率，杂散等
接收侧：接收灵敏度，多天线接收差，板间干扰等
3.环境因素
同频干扰
邻频干扰
低速率设备NAV
4.其他系统性能
CPU调度
管家管控
应用敏感性
三、分析方法
直接原因：wifi层面直接原因就是速率协商不上去，或者因为丢包重传导致掉速后又不能很快协商上来。
分析根本原因，就要建立在直接原因上去入手分析。
软件固件，硬件射频，天线都有可能导致速率协商不上去，掉速较快以及掉速后很久协商不上来。
1.首先确认tcp端口流
直接打开wireshark，从tcpdump或者空口log中过滤出tcp数据流。
这个步骤比较容易，因为一般吞吐量测试属于极限测试、后台不会挂其他应用。
使用magic iperf一般server端口为固定的5001，这样很容易找到对应的tcp长连接。
2.wireshark过滤空口tcp数据流
使用wireshark过滤规则：
tcp.port eq 5001 && ip.dst eq [] 可以过滤出相关流
3.wireshark的IO统计wifi速率变化
y轴取wlan_radio.data_rate，查看tcp流物理层速率变化。
四、发射和接收两方面分析
1.发送，过滤wlan.sa eq []
wireshark的IO统计wifi重传包-因为重传是引起掉速的直接原因
y轴取wlan.fc.retry，查看tcp流物理层速率变化。
wireshark的IO发射功率
y轴取wlan_radio.signal_dbm
2.接收部分
driver log中查看各个chain的rssi
wlan: [931:D:HDD] hdd_wlan_fill_per_chain_rssi_stats: 4316: RSSI for chain 0, vdev_id 0 is -54
wlan: [931:D:HDD] hdd_wlan_fill_per_chain_rssi_stats: 4316: RSSI for chain 1, vdev_id 0 is -68
fw log中查看误包情况
R0: FWMSG: [14a30036bc5] ANI_DBGID_POLL phyId 0 listen_time 61-61 ofdmPhyErrCnt 10 cckPhyErrCnt 3 ofdmPhyErrRate 163 cckPhyErrRate 49 level 2
四、根据结果综合分析
1.如果发送重传较多，一般为射频或天线问题
需要查看TRP指标，如果没问题。考虑天线阻抗或射频板间干扰。
2.如果发送重传不多，那考虑软件侧固件问题
3.如果接收误包较多，一般也为射频或天线问题
查看TSI指标，如果没有问题。考虑chain1等多天线间信号强度差异大，可以查看driver log中相关rssi。
4.如果接收误包率一致，考虑软件侧固件问题
--------
https://www.sohu.com/a/249405828_100256948
1、何为Wi-Fi吞吐量
a) 通俗的讲，Wi-Fi吞吐量即Wi-Fi设备（AP/STA）
在上行和下行链路上所支持的实际最大速率，属于一种极限测试，也较贴近用户实际使用场景，尤其在产品日趋无线化，有线网口设计逐渐淡出的今天，显得尤为重要。本文提及的Wi-Fi吞吐量均为应用层的Wi-Fi吞吐量测试，适用于高数据传输的应用场景
b) Wi-Fi吞吐量是一个较笼统的概念，在实际的测试中需要分模式，信道进行
如IEEE 802.11n HT40 mcs7 ch1, IEEE 802.11ac HT80 mcs9 ch36等。
注：MCS是Modulation and coding scheme，不同的数字代表不同的调制编码方式，不同的调制方式又对应不同的速率，具体可以查看802.11n/ac的协议。
c) 根据Wi-Fi吞吐量的验证目的（应用场景）不同，其方式也分为多种
1、比如验证Wi-Fi吞吐拐点时，需通过衰减器设置不同衰减值；
2、比如验证无线系统共存性能几种典型场景：
1）验证应用Wi-Fi+蓝牙combo芯片的产品共存性能（验证产品Wi-Fi与蓝牙时隙分配及信道避让机制，原理同4G与Wi-Fi共存），需开关该产品蓝牙功能进行试验；
2）单Wi-Fi设备测试吞吐时，外加蓝牙设备，还可细分至蓝牙只连接和数据传输两种状态；
3）Wi-Fi设备与Wi-Fi设备共存场景则是测试时外加其他Wi-Fi设备，该设备可工作在当前测试的同信道/相邻信道，同样可细分至只连接和数据传输两种状态；
3、比如验证Wi-Fi驱动影响，在近距离时较明显；
4、比如验证天线性能，就需要区分不同的方向角度、距离。
5、比如验证温度对吞吐量影响。也可根据需要对上述类型进行各种排列组合。
d) 如何判断Wi-Fi吞吐量好不好
如果要精益求精，以在干净稳定的环境下对比同种规格及模式的数据为基准。
一般说来，近距离零衰减下实测值需达到RF芯片理论值的一半以上，如理论速率150Mbps，最大测试值需在75Mbps以上；近距离加衰减下实测值跟Wi-Fi OTA的功率、灵敏度及天线性能相关，其性能好坏需以同等测试状态下的数据进行对比来判定。
此外，设计选型时需考虑产品自身数据传输要求的应用场景，以及产品设计时使用通信接口的最大理论速率，不可盲目追求使用高规格速率的Wi-Fi方案，造成设计成本浪费，如802.11ac HT80 1T/R最高理论速率能达到433.3Mbps，但产品使用的是SDIO V2.0通信接口，其实是无法达到理论值的一半的。
2、硬件影响要素
硬件上对吞吐量的影响可从芯片选型，layout设计，RF指标调试以及模具结构上来区分开来，这里只能简单概述。
a) 芯片选型---选择适合产品应用的芯片
跟吞吐量相关的参数有PHY layer data rate，support interface，typical conducted Tx power，typical EVM等等，此外，还需衡量芯片抗丢包的能力。物理层理论速率及所支持通信接口类型会直接决定以此芯片设计出来产品的吞吐量，功率决定传输距离，EVM决定信号调制质量。
b) Layout设计 （此处不做详细介绍）
这里主要集中在利用SI9000（或其他工具）选参考层，微带线50ohm的长短，走线的弯拐及阻抗控制，多路Wi-Fi信号的隔离，Wi-Fi部分电源的处理，以及干扰器件的布局，热设计，屏蔽设计等这些会影响到Wi-Fi射频指标。
c) 传导RF指标调
1. 发射功率，功率可以根据产品实际应用在设计上进行调整，功率大小跟传输距离的远近有直接关系。
2.这里还需要重点关注EV
它衡量的是解调出来的信号对应的调制方式理想星座图位置的偏移程度，EVM过差会导致符号错误，数据无法被确认接收，恶化为出错率，造成丢包。
3. 灵敏度
衡量设备的抗丢包能力，主要跟芯片能力以及layout布局相关，也可以通过屏蔽措施处理优化性能，需注意传导的验证方式只能部分反映产品抗干扰能力，Wi-Fi OTA的灵敏度测试才是较全面的验证。
d) 模具结构的设计
主要关注点在预留给天线设计的空间、天线的装配，以及整机结构的外观材质是否会影响无线信号传输。
e) 手工焊接的测试板卡
测试板卡如果芯片或者模组，以及Ipex端子是手工焊接的，也会影响到吞吐量性能。
f）天线的焊接
如果采用焊接式天线，其焊接至PCBA天线馈点处的同轴线芯线裸露在外也会影响到吞吐量；如果是金属贴片或者插件式天线，其上锡多少以及天线贴装的平整度同样会对吞吐量有影响。
3、软件影响要素
硬件工程师通常更多是关注EMC中的Wi-Fi杂散测试以及Wi-Fi传导指标，不太清楚软件工程师到底做了哪些修改，有时候如果软件工程师若没仔细核对代码，也会不清楚不同软件版本差异，因为中间还会涉及到芯片原厂是否有在底层做优化，结合实际经验，班妹建议应从如下方面注意：
a) 测试时设备是否被正确升级。有时如果软件包残缺或者损坏，升级后只能支持到部分模式和速率
b) 驱动版本是否正确。建议每一次驱动更新都需验证吞吐量。
c) 在驱动正确情况下， OS升级，是否有将优化性能的补丁打入
4、天线的影响要素
这里主要针对PCBA板卡 RF性能达标，模具确定后，整机的吞吐量验证。
天线是无源器件，主要影响OTA功率以及灵敏度，覆盖范围以及距离，而OTA则是分析解决吞吐量问题的重要手段，通常我们主要是针对如下参数衡量天线（以下参数不考虑实验室误差，实际天线设计性能好坏也会影响吞吐量性能）：
a) VSWR：衡量在天线馈点处输入信号的反射程度。这个值好不代表天线性能好，但是值不好，代表PCBA端输入到天线馈点处的能量被反射较多，相对驻波好的天线，能被用来辐射的功率已经减少较多。
b) 效率：天线辐射出去的功率与输入到天线馈点处的功率之比，该指标好坏会直接影响Wi-Fi OTA功率（TRP）以及灵敏度（TIS）性能。
c) 增益：表示输入同等功率时，在空间方向上的某个位置与理想点源天线在此处的功率比值，而OTA的无源数据通常为单个频率（信道）在球面的最大增益值，主要跟传输距离有关。
d) TRP/TIS：这两个综合性指标是通过对自由空间（可理解为OTA实验室环境）整个辐射球面求积分再取平均值所得，能直观（PCBA硬件+模具+天线的OTA性能）反映产品的Wi-Fi性能。
TRP/TIS测试与预期相差较多时，需要注意Wi-Fi是否进入低功耗模式，对使用电池供电的产品，测试时也需要检查其电量是否充足；此外TRP需关注ACK与non-ACK模式，而TIS一直都是OTA中的重点与难点，毕竟传导只能反映部分干扰情况，另外，软件因素也会对TIS有影响。
TRP/TIS可以作为Wi-Fi吞吐分析的重要手段。
e) 方向图：用来定性评估产品在空间的辐射覆盖范围，其测试数据通常也是按照频率（信道）来区分，每个频率都有H, E1，E2三个面，从而表征天线整个球面的信号覆盖情况。Wi-Fi产品在较远距离（距离较近时方向图无法表征）实际使用时，通过在多角度测试吞吐量来实际验证产品的无线信号覆盖范围。
f) 隔离度：隔离度衡量的是Wi-Fi多路天线的隔离程度，及天线间互耦情况，好的隔离度能减少天线间互耦，具备较好的方向图，从而整机具备较好的无线信号覆盖。
5、测试相关影响要素
测试时需注意以下细节
a) 测试环境的选择（这是吞吐量测试的痛点）
1、屏蔽暗室
研发阶段的分析验证建议在屏蔽暗室进行，以屏蔽多种无线信号的影响，尤其是Wi-Fi同频及邻频信号影响引起的信道拥塞及当前环境下理论速率的降低；可加衰减器模拟实际距离（不考虑多径、信号衰落影响），但此“距离的模拟”是建立在辅助测试Wi-Fi设备（AP/STA）的天线增益为“XXdBi”的前提下的，其实际意义多大，需实验者自己考虑，在同一场地的测试数据作为产品性能分析的数据库是没有问题的。
2、实际环境
在实际网络或者地下停车场的Wi-Fi吞吐量验证个人认为只能作为实验室验证完成后的实地辅助验证，已知的4G，蓝牙、Wi-Fi信号甚至某些无线信号倍频的干扰，以及建筑物、人员走动、车辆移动等都有较大影响。
b) 路由器选择
测试路由器所支持的模式及速率要高于受试设备，如设备为802.11n-HT40 2T/R，最高理论速率300Mbps，最好不要选用最大只能支持到300Mbps的路由器。至少要选802.11n-HT40 3T/R 450Mbps的路由器。
c) 测试APK的选择
常见的有Ix chariot以及Iperf。用Ixchariot时脚本建议选择high performance throughput ，在使用Iperf建议时间设置在60s，尽量减少测试偶然性。
d) 辅助测试电脑OS的影响
Windows 7和Windows 10会对结果有较大影响。
e) 路由器设置
测试时需设置切换路由器的模式，带宽，信道，所以要事先了解受试设备的规格
f) 受试设备与路由器相对位置及距离
每隔15°或者30°测试一次，测试距离根据自己产品的应用特性选择。
g) 受试设备的摆放位置
模拟用户正常使用，尽可能高些，与路由器处于同一水平面；也可自行设置极限位置测试。
小结
能够影响WiFi吞吐量测试的因素刚刚都已介绍过了，如果在实际运用中有帮到你们那么一丢丢，班妹就会很开心了。
由于吞吐量测试过于费时费力，且环境影响较大，建议还是在屏蔽环境中使用自动化测试较为节省时间，同时数据的 一致性也好。
关于WiFi吞吐量测试还有清楚想讨论的，可以随时留言哦，班妹看到后会第一时间回复的
WIFI Throughput 测试 debug 方法
1） 检查客户的 WLAN NV 是否和原理图设计匹配，
2） 请确认是 2.4GHz 的 Throughput 比较差还是 5GHz 的 Throughput 比较差
3） 请确认 ini 文件中的 40MHz BW 是否已经打开， 默认 ini 文件 40MHz 应该是关闭的。
gChannelBondingMode24GHz=1
gChannelBondingMode5GHz=1
注： 1 是 enable， 代表 40MHz 带宽打开， 如果 Ini 文件搜索不到这一项， 需要加上去
ini 文件路径： /data/misc/wifi/WCNSS_qcom_cfg.ini
Iperf： Throughput 测试 commands：
Please refer to the document
80-Y8113-11_E MU-MIMO Overview and Test Setup Guide
文档： 80-N2340-23_B_Debug_WLAN_Tput_Issues
80-N0365-1