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）
影響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.如果接收誤包率一致，考慮軟件側固件問題