無線問題FAQ手冊

無線問題FAQ

修訂記錄

日期修訂版本修改者修改描述

2018-7-241.0鄧星德初次編寫。

2018-7-261.1黃志鑫新增黃志鑫經(jīng)驗

2018-8-51.2鄧星德新增“Acer筆記本連接無線速率只有54M”；

“MW3IXIA儀器256b丟包率問題”；“F3V4.0STA影

響AP切頻寬”;“Mtk76x2e掃描不到信號”；“測試方

法內(nèi)容更新”

2018-11-191.2王航增加“AC11MU-MIM0性能差問題”

目錄

無線問題FAQ.........................................................................................................................................1

修訂記錄.........................................................................1

目錄.............................................................................1

性能問題.........................................................................2

模版-性能....................................................................2

W20EV1.0干擾性能分析......................................................3

VI200IXIA無線轉(zhuǎn)發(fā)率TX低于競品30%..............................................................................7

MW3IXIA儀器256字節(jié)丟包率97%.....................................................................................10

功能問題........................................................................21

模版-功能...................................................................21

掃描gb2312的10個中文字符以上ssid,亂碼或死機............................22

O3V3.0無線模塊無法卸載....................................................24

蘋果手機關(guān)聯(lián)AC10異常，EDCA相關(guān)........................................25

F3V4.0STA影響AP切頻寬..................................................25

I21-CE認證降功率...........................................................29

Mtk76x2e掛機出現(xiàn)蘋果手機、電腦無法掃描到信號.............................33

體驗問題........................................................................38

模版-體驗...................................................................38

AC6V1.0無線終端連接慢....................................................39

Acer筆記本（2T2Rlln）連接無線速率為54M....................................................................40

手機連接上121,5分鐘內(nèi)掉線問題...........................................43

射頻問題........................................................................45

測試方法........................................................................45

IXIA-無線轉(zhuǎn)發(fā)率測試........................................................45

IXIA-無線帶機量性能........................................................46

IXIA-無線轉(zhuǎn)發(fā)時延..........................................................47

IXIA-無線轉(zhuǎn)發(fā)丟包率........................................................47

性能問題

模版-性能

問題描述

BUG-ID分析人

硬件方案軟件規(guī)格

產(chǎn)品名稱SVN解決版本號

SVN路徑

測試環(huán)境

網(wǎng)絡(luò)拓撲

Aaa

測試步驟

aaa

分析與調(diào)測過程

aaa

W20EV1.0干擾性能分析

問題描述5樓干擾環(huán)境下，穿3堵墻后，W20E2.4G吞吐量低于競品TL-WRI300G

BUG-ID分析人鄧星德

硬件方案BCM43217軟件規(guī)格

產(chǎn)品名稱SVN解決版本號

SVN路徑

一臺工控機，一臺筆記本，安裝"Chariot6.7"、"Endpoint”軟件；

測試環(huán)境有線網(wǎng)卡Intel(R)82583VGigabitNetworkConnection,驅(qū)動版本；

無線網(wǎng)卡TP-WDN4600,驅(qū)動版本；

網(wǎng)絡(luò)拓撲

房間1房間2房間3房間4

DUT

L---------Z

STA1

測試步驟

1.開啟房間1中的干擾源(商用)

2.將DUT放置在房間1中，分別配置為lch,5ch,9ch,20M頻寬。

3.STA1通過LAN口連接到DUT,STA2通過無線連接到DUT,通過ixcharit跑流。

分析與調(diào)測過程

通過以往的經(jīng)驗，在干擾環(huán)境下，適當(dāng)?shù)臏p少接收靈敏度，可以有效的抑制干擾信號，提升設(shè)備的

抗干擾能力。W20E的2.4G射頻使用BCM43217,其為NPHY,因此對應(yīng)的11B的接收靈敏度寄存器

地址為0x289.我們針對該寄存器進行調(diào)測：

方

配置TXlTX2TX3平均RX1RX2RX3平均

案

默認配置：

1

wlinterference432.130.331.531.38.910.29.29.43

wlinterference0

2

wlphyreg0x2890x9f33.231.231.6327.38.99.58.56

wlinterference0

3

wlphyreg0x289Oxbf48.946.248.547.8612.211.513.112.26

wlinterference0

4

wlphyreg0x289Oxdf46.747.248.447.4311.711.912.311.96

通過以上測試可以看出，對UB接收靈敏度進行微調(diào)后，干擾環(huán)境下的性能有所改善，使用方案3

（接收門限在-85db左右）能達到最佳的效果。

在接收靈敏度優(yōu)化的方案上，調(diào)整速率優(yōu)化算法，測試干擾環(huán)境下的性能:

測試項TXlTX2TX3平均RXlRX2RX3平均

W15E48.245.149.647.6333312.511.714.412.86667

W15E+速率優(yōu)化50.350.151.550.6333313.412.613.813.26667

從測試情況可以看出，加入速率優(yōu)化后，TX的性能有所提升，RX提升不明顯。

綜上：在W20E的性能優(yōu)化中，我們采用調(diào)整11B接收門限+速率優(yōu)化的方式。

優(yōu)化后，性能對比：

測試設(shè)備信道TXRX

Ich54.220.2

5ch56.224.5

W20E

9ch60.324.2

平均56.922.9

Ich26.22.6

5ch31.12.6

AC6

9ch35.26.6

平均30.833333.933333

競品Ich75.2033.5

TL-WR1300G5ch66.8040.5

9ch59.2040.8

平均67.0738.2

通過以上測試可以看出：

W20E與AC6采用同樣的硬件方案，W20E在經(jīng)過優(yōu)化后，干擾環(huán)境下的性能優(yōu)于AC6;但W20E與

競品TL-WR1300G相比，在TX上相差11M,RX相差16M;在干擾環(huán)境下，與競品的差距比較明顯。

差距分析

A.接收靈敏度的影響

隨著接收靈敏度的降低，設(shè)備接收的干擾信號越少，在保證有用信號能夠正常接收的情況下，

盡可能的降低接收，可以提升設(shè)備的抗干擾能力，但接收靈敏度在軟件上只能在一定的范圍內(nèi)

調(diào)整，因此為了降低更多的接收，我們?nèi)サ鬢15E的外部低噪放，改成內(nèi)部低噪放，這樣一來，

可以在原有的接收寄存上降低lOdbm。以下為對比測試數(shù)據(jù)：（W15E與W20E使用同樣的芯片方

案）

設(shè)置設(shè)備信道TXRX

Ich50.118.2

5ch47.517.6

W15E_外部低噪放

9ch48.919.2

平均48.8333318.33333

Ich58.228.5

5ch56.829.1

W15EJJ用內(nèi)部低噪放

9ch60.230.3

平均58.429.3

通過測試我們可以看到：改用內(nèi)部低噪放后，TX和RX的性能都有10M的提升。說明盡一步的

降低接收門限，可以提升抗干擾性能。但改用內(nèi)部低噪放后，W15E的覆蓋性能下降明顯，在

8樓的覆蓋環(huán)境中，無法達到測試標準。因此在覆蓋范圍和抗干擾之間需要做出平衡。W15E任

然使用外部低噪放的設(shè)計方式。

B.芯片方案間的差異

在屏蔽房環(huán)境中，對比AC6（W15E同樣方案），TL-WDR6500等方案在天線分集上的指標:

AC6_TP0500_斐訊K2

11a分集對比.docx

從測試結(jié)果反映：

1.博通系列的產(chǎn)品，在接收上是選擇靈敏度最優(yōu)的一根進行數(shù)據(jù)處理。

2.TP系列（高通）的產(chǎn)品，在接收上采用多天線加權(quán)的處理方式，整體的接收靈敏會比單天線多

3dbm（總共2天線）

為了進一步說明接收兩種方案在接收機制上處理的差異，我們在實際環(huán)境中進行了性能測試:

測試環(huán)境：

8樓無干擾環(huán)境，穿3堵墻

測試設(shè)備：

DELL筆記本（1x1無線網(wǎng)卡），W15E,TL-WVR-1300G

測試步驟：

1、測試TL-WVR-1300G多天線，單天線下的RX性能

2.測試W20E多天線，單天線下的RX性能

測試結(jié)果：

測試123平均RSSI

TL-WVR-3天線工作31.130.932.831.6

TL-WVR-天線0工作18.520.921.320.23333

TL-WVR-天線1工作9.512.210.310.66667

TL-WVR-天線2工作26.725.525.325.83333

W20e-2天線工作20.121.422.921.46667-63dbm-57dbm

W20e-天線0工作28.327.928.128.1-63dbm

-57dbm

W20e-天線1工作20.522.522.821.93333

從測試結(jié)果可以看出，TP的產(chǎn)品多根天線性能最優(yōu)。W20E多天線性能與天線1的性能相當(dāng)。

按照之前的理論，博通產(chǎn)品在接收上會選擇接收最好的一根處理（此時天線1的RSSI最好）。所以W20E

在此環(huán)境下RX比競品低的主要原因：

1.TP（高通方案）發(fā)揮了多根天線加權(quán)的特性，提升接收的靈敏度

2.W20E（博通方案）接收上，選擇其中一根（RSSI最優(yōu)）進行處理，并沒有提升整體的增益。

總結(jié)

1.W20E性能優(yōu)化采用調(diào)整接收靈敏度與速率算法優(yōu)化的手段，優(yōu)化后，在干擾環(huán)境穿3堵墻，性能可

從32M提升到48M。

2.射頻鏈路上去掉外部低噪放，改用內(nèi)部，TRX性能有10M的提升，考慮到設(shè)備的覆蓋能力，無法直

接采用該方案。

3.高通與博通方案在MIMO下的信號處理存在著差異，TPLINK發(fā)揮了多天線信號加權(quán)的特性，對接收

增益有一定的提升。

后續(xù)可優(yōu)化的方向：

1.從降低接收可以提升設(shè)備的抗干擾能力的方向入手：

A.射頻設(shè)計上加大臨頻/同頻干擾信號的過濾處理。

B.軟件上，分析接收增益調(diào)整相關(guān)的寄存器，嘗試通過調(diào)整寄存器，控制信號增益，從而降低臨

道信號的干擾。

2,推動原廠優(yōu)化多天線信號的處理機制，提升接收增益。

V1200IXIA無線轉(zhuǎn)發(fā)率TX低于競品30%

V1200IXIA無線轉(zhuǎn)發(fā)率低于競品30%

_______UDP-TX

DUT競品

問題描述20.419.56

99.697.06

187.9212.87

451.9625.37

BUG-ID分析人鄧星德

硬件方案軟件規(guī)格

產(chǎn)品名稱SVN解決版本號

SVN路徑

測試環(huán)境IxiaVeriwave

網(wǎng)絡(luò)拓撲

測試步驟

1.打開Waveapp軟件，選擇thourghtput測試項目，配置方法見IXIA-無線轉(zhuǎn)發(fā)率測試

2.IXIA有線口連接DUTWAN口

3.無線配置為WPA/WPA2(TKIP+AES)加密方式，149信道，80M頻寬

4.IXIA配置ETH->Wireless方向

5.run

分析與調(diào)測過程

~"由于測試項目較大，問題排查只針對1518字節(jié)數(shù)據(jù)進行分析

1.數(shù)據(jù)口走WAN,首先先排除NAT的影響

將IXIA有線連接DUTLAN口，測試對比WAN口性能。兩者性能相當(dāng)，排除WAN口影響

2.排除環(huán)境原因，導(dǎo)致無線傳輸有丟包，發(fā)送速率沒有到達最佳狀態(tài)

測試過程中，通過wlrate命令，可以看到DUT的發(fā)送速率保持在866,所以發(fā)送速率正常

3.排查CPU滿載的影響

測試過程中，通過top命令查看CPU的使用率；可以看到CPU滿載了。所以問題在與CPU資源消耗

完了，V1200使用的是BCM63167,其CPU為400M雙頻，CPU能力較差。

4.對于SDK軟件，排除tenda自己修改的代碼導(dǎo)致CPU開銷增大。

WPA/WPA2-TKIP+AES

V1200506

SDK5.02L_.03506

可以看到V1200與其使用的SDK5.02L_0.3性能相當(dāng)。因此SDK也存在同樣的問題，將問題反饋給原

廠

5.由于競品使用的方案與V1200一樣，理論上在使用同樣的軟件上，兩者性能應(yīng)該相當(dāng)；競品是兩年

前的產(chǎn)品，使用的SDK較老，通過串口查看競品日志，可以看到競品使用的是4.16版本的SDK。因

此對比不同的SDK軟件，驗證我們的猜測

WPA/WPA2-TKIP+AESWPA/WPA2-AESOPEN

V1200506573586

SDK5.02L_.03506573586

SDK4.16L_.O5561633637

V400561649651

通過測試可以看到，競品V400性能與SDK4.16L相當(dāng)，而SDK5.02與V1200相當(dāng)。

6.由于5.02與4.16之間除了無線驅(qū)動有差異，同時內(nèi)核版本也存在差異5.02使用4.1版本Liunx;4.16

使用3.4X版本。對比更多相近的SDK版本，進一步排查linux內(nèi)核和驅(qū)動之間的影響程度。

SDK版本OPEN

5.02L01_wlan7.14.131.47599

5.02L.03_wlan7.14.164.19574

4.16L.05_wlan7.14.131.1608651

4.16L.05_wlan7.14.164.19621

不同驅(qū)動間對性能有影響，低版本的無線驅(qū)動更優(yōu)，7.14.131優(yōu)于7.14.164(599-574)+(651-621)

/2=27M

不同內(nèi)核版本對性能的影響，3.X內(nèi)核優(yōu)于4.X內(nèi)核(651-599)+(621-574)/2=50M

7,由于差異主要是SDK版本差異導(dǎo)致，屬于原廠問題；再推動原廠解決的同時，軟件上也嘗試以下優(yōu)

化，但效果不明顯

方案優(yōu)化點結(jié)果

1移植fastnat降低200M

2移植基于Linux的設(shè)備快轉(zhuǎn)降低150M

3優(yōu)化EDCA無改善

4同步V400無線NVRAM配置無改善

5裁剪ffDS模式無改善

6裁剪STA模式無改善

7裁剪802.11D無改善

8調(diào)整AMPDU緩存隊列無改善

9調(diào)整AMPDU聚合SIZE無改善

10CPU超頻硬件已經(jīng)最高頻率；軟件上無法控制

差距分析

問題原因在于SDK差異，而SDK差異最大的影響是Linux版本，5.02使用的4.1版本內(nèi)核很新，一些

內(nèi)核公共接口進行了豐富，可能導(dǎo)致無線驅(qū)動轉(zhuǎn)發(fā)處理的代碼指令開銷增大，從而CPU資源消耗的更

多

總結(jié)

通過調(diào)整無線的加密方式，5GIXIA可以測試到574M,與競品V400任存在70M的差距(相較于上

一輪轉(zhuǎn)測試170M的差距，有所改善）。

關(guān)于70M的差距，進一步對比SDK版本和無線驅(qū)動，其中內(nèi)核版本的差異影響50M,無線驅(qū)動影響

20Mo

目前V1200使用4.1版本Linux,V400使用3.4版本Linux,linux屬開源代碼，由于兩個不同版本代

碼差異很大，難以定位到差異點（同步和原廠方面溝通過，Linux的差異屬于開

源社區(qū)，不屬于BRCM模塊問題，無法推動解決）。

關(guān)于無線驅(qū)動部分的差異，采用較老的驅(qū)動可以提升20M吞吐量，但基于5.02L0.3的SDK軟件，BRCM

方面沒有對老版本驅(qū)動進行維護，沒有相關(guān)補丁/無法回退到低版本驅(qū)動上。

MW3IXIA儀器256字節(jié)丟包率97%

問題描述MW3IXIA儀器256字節(jié)丟包率97%

BUG-ID分析人曹杰

硬件方案8197F+881264M內(nèi)存軟件規(guī)格

產(chǎn)品名稱MW3SVN解決版本號

SVN路徑33:18080/svn/EROS/SourceCodes/Branches/EROS_MESH/develop_svn1350

測試環(huán)境

網(wǎng)絡(luò)拓撲

問題環(huán)境：

IXIA-LAN--MW3-WAN,

IXIAWIFIMW3-WLAN5G

簡化驗證環(huán)境：

PCIETH一一MW3WAN

MW3WLAN—PC2WLAN

測試步驟

1.使用IXIA儀器測試設(shè)備WAN到WLAN的256字長的丟包率，丟包率97%

分析與調(diào)測過程

1.問題分析：由于數(shù)據(jù)包的流向是以太網(wǎng)口到無線，因此先確認以太網(wǎng)口接收數(shù)據(jù)包的情況，通過統(tǒng)

計查看發(fā)現(xiàn)以太網(wǎng)驅(qū)動的統(tǒng)計cat/proc/rtl865x/stats發(fā)現(xiàn)較多的rx_noBuffer_cnt丟包，由此初步判

斷是以太網(wǎng)口接收緩存不足導(dǎo)致的丟包。

-#cat/proc/rtl865x/stats

Debugstatisticsinfo:

etn_skb_free_num:276(pool276,rtk_que0)

rx_noBuffer_cnt:4637_

tx_ringFull_cnt:s\

tx_drop_cnt:

statist!c_total:22605\

statistic_ps:4732

statistic_ipv6__fp:0

statistic_fp:32305247

cnt_swcore:128250

cnt_swcore_tx:2169

cnt_swcore_rx:126867

cnt_swcore_link:3

cnt_swcore_err:304

runoutlrq:disable

freeskbThreshold:128

2.丟包率測試的原理分析：根據(jù)儀器測試原理及抓包分析，測試丟包率的原理是儀器按照設(shè)定的包長的

發(fā)包速率進行發(fā)包，在我們的測試用例中，發(fā)包速率為特定幀長的線速，以256字節(jié)為例，發(fā)包速率為

45289pps,即百兆端口的線速發(fā)送256字節(jié)的數(shù)據(jù)包。

3.調(diào)試環(huán)境構(gòu)建：由于測試環(huán)境比較緊張，為方便調(diào)試，使用兩臺PC,嘗試構(gòu)建256字節(jié)WAN到無線

線速發(fā)包的測試環(huán)境，如簡化驗證環(huán)境之后的拓撲所示，常用的吞吐量測試軟件有iperf和ixchariot等

等，經(jīng)過抓包分析，發(fā)現(xiàn)ixchariot在跑流量過程中會有較多的交互報文，不適合小包單向的場景，而iperf

工具在進入穩(wěn)定的跑流狀態(tài)后，幾乎沒有非流量的報文，因此更適合用于模擬儀器WAN到無線的小包。

iperf百兆速率發(fā)送UDP抓包情況如下:

9^1

?ltatimeSourceDestinationProtocol

242In-O

)00015000192.168.0.99103UDP242Sourceport:5201Destinationport:61577

)00011000192.168.0.99103UDP242Sourceport:5201Destinationport:61577

>00012000192.168.0.99103UDP242Sourceport:5201Destinationport:61577

)00011000192.168.0.99103UDP242sourceport:5201Destinationport:61577

)00270000192.168.0.99103UDP242sourceport:5201Destinationport:61577

)00017000192.168.0.99103UDP242Sourceport:5201Destinationport:61577

)00011000192.168.0.99103UDP242Sourceport:5201Destinationport:61577

)00012000192.168.0.99103UDP242Sourceport:5201Destinationport:61577

)00018000192.168.0.99103UDP242sourceport:5201Destinationport:61577

)00016000192.168.0.99103UDP242Sourceport:5201Destinationport:61577

)00016000192.168.0.99103UDP242Sourceport:5201Destinationport:61577

)00016000192.168.0.99103UDP242Sourceport:5201Destinationport:61577

)00015000192.168.0.99103UDP242Sourceport:5201Destinationport:61577

)00016000192.168.0.99103UDPSourceport:5201Destinationport:61577

3.問題復(fù)現(xiàn)：WAN側(cè)PC使用iperf-s命令啟動iperf服務(wù)端

LAN側(cè)PC使用iperf-c9-1200-u-b100M-R-t1000發(fā)包，通過調(diào)整iperf的參數(shù)并抓包

確認發(fā)送數(shù)據(jù)包的大小及方向與儀器環(huán)境一致后，開始觀察跑流的情況

558.38-59-41sec215KBytes1.71Mbits/sec1102

559.41-60-24sec161KBytes1.58Mbits/sec825

560.24-61-47sec269KBytes1.79Mbits/sec1375

561.47-62-41sec161KBytes1.40Mbits/sec825

562.41-63.53sec215KBytes1.58Mbits/sec1100

563.53-64.41sec161KBytes1.49Mbits/sec825

564.41—65.25sec214KBytes2.09Mbits/sec1098

565.25-66.41sec215KBytes1.52Mbits/sec1102

566.41-67.59sec215KBytes1.49Mbits/sec1100

567.59-68.41sec161KBytes1.61Mbits/sec824

568.41-69.06sec376KBytes4.73Mbits/sec1923

569.06-70.26sec591KBytes4.03Mbits/sec3025

570.26-71.60sec269KBytes1.64Mbits/sec1375

571.60-72.41sec161KBytes1.63Mbits/sec825

572.41-73.60sec215KBytes1.48Mbits/sec1100

573.60-74-41sec161KBytes1.63Mbits/sec825

574.41-75-27sec215KBytes2.05Mbits/sec1100

575.27-76-41sec215KBytes1.54Mbits/sec1100

576.41-77-62sec215KBytes1.45Mbits/sec1099

577.62-78-41sec214KBytes2.22Mbits/sec1098

578.41-79.00sec279KBytes3.88Mbits/sec1430

579.00-80.03sec150KBytes1.20Mbits/sec769

580.03-81.07sec429KBytes3.38Mbits/sec2198

581.07-82.10sec161KBytes1.28Mbits/sec825

582.10-83-13sec215KBytes1.71Mbits/sec1100

百兆速率發(fā)包吞吐量只有2Mbps左右，且rx_noBuffer_cnt增力口得也比較快，由此證明問題在構(gòu)造的簡

化環(huán)境中也能夠復(fù)現(xiàn)。

4.調(diào)測過程：首先排除應(yīng)用層的影響，由于無線客戶端連接到無線獲取到IP地址整個流量測試過程中不

需要應(yīng)用層的程序參與，所以可以使用echoi>/proc/sysrq-trigger關(guān)閉所有應(yīng)用層程序，排除應(yīng)用

層的干擾，關(guān)閉所有應(yīng)用層進程后，發(fā)現(xiàn)吞吐量從2M左右提升到60M左右,統(tǒng)計中rx_noBuffer_cnt

也不再增加。

[5110.00-11.00sec7.12MBytes59.SMbits/sec

[5]11.00-12.00sec7.53MBytes63.1Mbits/sec39466

[5]12.00-13.00sec5.55MBytes46.6Mbits/sec29108

[5]13.00-14.00sec7.58MBytes63.6Mbits/sec39747

[5]14.00-15.00sec7.56MBytes63.5Mbits/sec39660

[5]15.00-16.00sec7.56MBytes63.4Mbits/sec39651

[5]16.00-17.00sec7.56MBytes63.4Mbits/sec39626

[5]17.00-18.00sec7.56MBytes63.5Mbits/sec39636

[5]18.00-19.00sec7.57MBytes63.5Mbits/sec39678

：5319.00-20.00sec7.59MBytes63.7Mbits/sec39810

[5]20.00-21.00sec7.57MBytes63.5Mbits/sec39692

[5121.00-22.00sec7.59MBytes63.7Mbits/sec39818

[5]22.00-23.00sec7.59MBytes63.7Mbits/sec39806

[5]23.00-24.00sec7.59MBytes63.7Mbits/sec39799

：5]24.00-25.00sec7.58MBytes63.6Mbits/sec39747

[5]25.00-26.00sec7.42MBytes62.3Mbits/sec38928

[5]26.00-27.00sec7.59MBytes63.7Mbits/sec39808

：5]27.00-28.00sec7.58MBytes63.6Mbits/sec39738

[5]28.00-29.00sec7.58MBytes63.6Mbits/sec39760

[5]29.00-30.00sec7.58MBytes63.6Mbits/sec39745

[5330.00-31.00sec7.60MBytes63.8Mbits/sec39868

由次猜測可能由于應(yīng)用層注冊收包接口未處理或未及時處理報文導(dǎo)致，重點先排除向內(nèi)核注冊了接收所

有數(shù)據(jù)報文的socket的應(yīng)用層。

查看內(nèi)核注冊的收包接口情況如下:

?#cat/proc/net/packet

skRefCntjypeProtoifaceRRmemuserInode

82554C00300030118066405613

8255500033890d201005592

830e6000310000320118280001931

協(xié)議類型為3表示監(jiān)聽所有的內(nèi)核所有的數(shù)據(jù)包，通過查看代碼發(fā)現(xiàn)注冊的AP_PACKET_ALL的應(yīng)用

層進程是pathsei和pann,因此優(yōu)先殺掉了這兩個進程，問題并沒有改善。接著繼續(xù)關(guān)閉其他應(yīng)用

層進程，按照猜測的順序逐個關(guān)閉應(yīng)用層進程，直至關(guān)閉掉redis-server進程后流量才恢復(fù)正常，

但是查看svn記錄發(fā)現(xiàn)這個服務(wù)在最近并沒有代碼修改，屬于比較穩(wěn)定的模塊，因此初步排除了與

應(yīng)用層程序的關(guān)聯(lián)。

觀察內(nèi)存使用情況，發(fā)現(xiàn)系統(tǒng)啟動后剩余內(nèi)存為18M左右，關(guān)閉所有的應(yīng)用層進程后內(nèi)存剩余28M左

右，逐個關(guān)閉應(yīng)用程序直至流量恢復(fù)正常的時候，內(nèi)存剩余為21M左右，由此猜測系統(tǒng)剩余內(nèi)存

影響了以太網(wǎng)就收緩存區(qū)的分配，走讀以太網(wǎng)接收數(shù)據(jù)包的代碼，數(shù)據(jù)緩存分配的大致流程如下：

優(yōu)先使用以太網(wǎng)驅(qū)動預(yù)分配的地址池，地址池用完后就從系統(tǒng)中使用再從系統(tǒng)中分配內(nèi)存，這里還

做了一個限制，當(dāng)系統(tǒng)內(nèi)存小于20M時，如果預(yù)分配的地址池用完，不再通過系統(tǒng)分配內(nèi)存，主

要的原因是產(chǎn)品使用的是64M的內(nèi)存，剩余內(nèi)存較小，為避免接收緩存消耗掉過多的內(nèi)存導(dǎo)致系

統(tǒng)運行不穩(wěn)定，所以做了這個限制。

if(rx_skb_queue.qlen=0){

#ifdefined(CONF工G_RT[_ETH_PR工v_5KB)

new_skb=dev_al1oc_skb_priv_eth(CROSS_LAN_MBUF_LEN);

if(new_skb=NULL){

structsysinfomem_info;

unsignedim

si_meminfo(&mem_info);

if(K(mem_info.totalram)>64000){

imit=5000:

}else{

mem_limit=20000;

}

ifnfo.freeram)>{

new_skb=dev__al1oc_skb(cROsS_LAN_MBUEN);

}

}

#else

new-skb=dev_al1oc_skb(CROSS_LAN_MBUF_LEN);

#endif

if(new_skb=NULL){

DEBUG_ERRC'EthDrv:allocskbfailed[5');

)

else

skb_reserve(new_skb,RX_OFFSET);

但是就目前的剩余內(nèi)存來看，系統(tǒng)啟動后剩余內(nèi)存就已經(jīng)處于限制的邊界，小包UDP需要處理的包數(shù)

又很多，所以很容易導(dǎo)致預(yù)分配地址池資源用完的情況，將此處的保留內(nèi)存限制修改為15M后，吞吐

量能跑到與關(guān)閉所有應(yīng)用層的結(jié)果接近，且rx_noBuffer_cnt不會快速增加，由此確定了產(chǎn)生丟包問題的

原因。

問題回歸：為分析問題方便，構(gòu)建了一個簡單的測試環(huán)境，并驗證修改點有效后，最終還是要到儀器測

試環(huán)境中回歸問題。對比修改前后的版本，修改前256字節(jié)丟包率97%,修改后多次測試丟包率為10%

左右，有了很大的改善。

差距分析

對于數(shù)據(jù)包轉(zhuǎn)發(fā)來說，如果轉(zhuǎn)發(fā)的效率越高，需要的接收緩存區(qū)就會越小，消耗的內(nèi)存資源也就越少，

本問題雖然通過增加接收緩存區(qū)改善了丟包情況，但是問題也有可能能夠從提升WAN到無線的轉(zhuǎn)發(fā)效

率方面入手去改善，數(shù)據(jù)包轉(zhuǎn)發(fā)的效率與地址池分配以及如何滿足小包極端情況（小包線速）下的突發(fā)

的空間需求，有幾個值得思考的問題，如何量化數(shù)據(jù)包的轉(zhuǎn)發(fā)效率？根據(jù)轉(zhuǎn)發(fā)效率如何確定預(yù)分配地址

池的大小？

總結(jié)

1.理解測試原理，逐步分析導(dǎo)致丟包的原因。

2.儀器環(huán)境緊張時可以考慮自己構(gòu)建分析問題的環(huán)境進行復(fù)現(xiàn)并分析問題。

3.5G選擇干凈的信道也可以驗證一些性能相關(guān)的問題。

贈品（Realtek方案支持非常用信道的方法）

iwprivwlanOset_mibcountrystr=DD;iwprivwlanOset_mibregdomain=16;iwprivwlanOset_mib

channel=64;ifconfigwlanOdownup

country設(shè)置為不存在的