admin 管理员组文章数量: 1086019
2024年4月29日发(作者：同步fifo和异步fifo的区别)
FTP下载业务由于传输受限导致下载速率低问题
问题描述：
当服务器、核心网、eNodeB之间的传输存在问题时，会造成终端的下行速率低。本文以定位某站点近点测试FTP
下行速率低问题为例，通过此问题分析，隔离定位出导致速率低的根因为传输导致。
分析定位过程：
1、处理思路
先确定是否空口质量问题，通过观察RSRP、SINR信道质量指标进行分析；排除空口质量问题后，如果是FTP问题，
需要首先使用UDP灌包排查传输问题；（FTP属于TCP业务，TCP本身通信机制较为复杂，一般都需要抓包进行分析，
对于一般速率问题，首先推荐使用UDP灌包进行排查。若UDP灌包速率存在问题，首先解决UDP灌包速率问题）
2、关键过程
现场进行问题复测，测试方法：先使用FTP软件从服务器直接下载文件，再使用iperf软件从服务器侧向UE灌
100mbps的UDP包进行对比测试，在服务器、eNodeB和UE侧观察下行接受速率。
1）服务器侧直接从iperf软件读取从网卡发出的速率；
2）eNodeB侧使用MML命令DSP IPPATH查询从核心网接收到的实时速率；
3）UE侧使用Probe观察MAC层的接受速率。
通过测试，得出如下结论：
1）可排除信号原因。下行信号很好，RSRP = -61dBm，SINR = 36.7dB，下行下载没有误包。
2）排除UE开户速率低原因。与现场同事确认，该UE及SIM卡在其他站点测试都没有问题，FTP下载速率都可以达
到30mbps以上。
3）排除上行链路原因。FTP下行下载和UDP下行灌包，从eNodeB和UE侧观察，2种方法的测试速率都在970kbps
左右， TCP（FTP业务）与UDP的机制不同（TCP需要上行反馈，UDP不需要上行反馈），同时，进行上行UDP灌包，
UE和eNodeB观察的上行速率都为6mbps左右，通过上述测试可以排除上行链路的影响。eNodeB侧MML命令查询上行
实时速率如下图：
To query the parameters of an IP path, run the following command:
DSP IPPATH: PATHID=0;
The result is shown as follows:
+++ HUAWEI 2012-10-31 16:20:19
O&M #41
%%DSP IPPATH: PATHID=3;%%
RETCODE = 0 Operation succeeded
DSP IP Path Result
------------------
IP Path ID = 3
Non-Realtime Reserved TX Bandwidth(Kbit/s) = 0
Non-Realtime Reserved RX Bandwidth(Kbit/s) = 0
Realtime TX Bandwidth(Kbit/s) = 6351
Realtime RX Bandwidth(Kbit/s) = 4
Non-Realtime TX Bandwidth(Kbit/s) = 0
Non-Realtime RX Bandwidth(Kbit/s) = 0
Transport Resource Type = High Quality
IP Path Check Result = normal
(Number of results = 1)
--- END
4）可排除空口原因。上行和下行UDP灌包，在UE侧和eNodeB的实时速率观察，显示速率一致，如下图：
%%DSP IPPATH: PATHID=0;%%
RETCODE = 0 Operation succeeded
DSP IP Path Result
------------------
IP Path ID = 2
Non-Realtime Reserved TX Bandwidth(Kbit/s) = 0
Non-Realtime Reserved RX Bandwidth(Kbit/s) = 0
Realtime TX Bandwidth(Kbit/s) = 194
Realtime RX Bandwidth(Kbit/s) = 967
Non-Realtime TX Bandwidth(Kbit/s) = 0
Non-Realtime RX Bandwidth(Kbit/s) = 0
Transport Resource Type = High Quality
IP Path Check Result = normal
(Number of results = 1)
--- END
5）确认为服务器到eNodeB的传输有问题。通过UDP灌包，在服务器、eNodeB和UE侧的实时速率观察对比：
➢
➢
➢
UE接收到的UDP速率为943kbps
eNodeB接收到的速UDP速率为970kpbs
服务器下发的UDP速率为92mbps
测试截图如下：
同时通过MML命令检查eNodeB的以太端口配置速率为1000mbps。
该服务器在其他站点测试均正常，故排除服务器到核心网的问题，可以确定是传输限速导致，需要推动客户解决
传输问题。
根因：
核心网-eNodeB的传输速率受限，使到达eNodeB的速率已经很低，导致空口速率低。
解决方案：
建议与总结：
一般传输类问题，通过ping、UDP灌包可进行初步的排查，方法以及判断标准参考：
通过准则:不能有丢包
1、LST IPRT，查看SGW IP地址
2、从基站对上述每个地址进行PING包，1000/2000各100次
1、PING包检查
推动传输解决速率受限问题。
2、灌包检查
测试原理：
Ping包检查传输问题最基础测试，但ping包流量较小，在大流量情况下，如果出现发送流量超过传输数据缓冲区，
有可能导致丢包，这必须在大流量场景下才可以暴漏该问题。
测试前准备：
一台PC机，作为灌包服务器。（最好安装Windows Server 2003系统，若无可用Win Xp系统，WIN7系统较为复杂，
性能无法保证。）
通过准则：基站入口处实时流量和灌包流量基本一致，吞吐量损失可在10%以内。即灌包速率100Mbps，message
中看到从终端PC上实际发出92-95M（受PC性能影响），基站接收大于85Mbps。
1）接入UE，下行灌包，如下图所示：
灌包100M，MTU设置1400，勾选Message，在右侧窗口查看实际灌出的流量
2、基站侧检查S1入口实时流量是否和灌包流量相符，如果不符，则认为传输有问题，DSP ETHPORT，查看“实际
接收流量”：
查询命令
查询结果
关键字：
FTP下载速率，传输，限速
版权声明：本文标题：FTP下载业务由于传输受限导致下载速率低问题 内容由网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：http://www.roclinux.cn/b/1714380052a677616.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。
发表评论