单线程速率低业务面定位方法总结.docxVIP

单线程下载速率低业务面定位过程总结（龚莉）一．问题现象：十堰使用单线程下载速率只能到700K左右，但是使用多线程可以达到950K左右。二．定位思路和过程：根据通常的经验，定位业务速率异常的问题首先需要分析网络是否存在大量丢包，数据包延迟是否大，而丢包在端到端的各个环节都有可能产生，一般需要在终端抓取WIRESHARK数据，基站抓取物理层和FP数据，RNC抓取业务面跟踪和QOS跟踪，通过下面的方法逐步定位：总体情况快速了解：分析终端WIRESHARK抓包，通过专家信息初步得到丢包、重传情况，通过统计信息中的IO graphs确认速率情况。确认是否和无线环境及服务器相关：分析定点情况下的速率，如果定点情况下速率正常，一般不怀疑无线环境和服务器问题，十堰定点测试速率可以达到1.5M。因此基本可以确定和无线环境及FTP 服务器没有关系，速率低应该是RAN的设备问题或者参数设置问题，也可能和终端的处理能力相关。确认UU口层2丢包是否严重：可以在LDT上进行用户的QOS根据，在用户业务保持一段时间后检查跟踪结果，QOS跟踪可以周期统计上下行流量以及上行误块的数量和下行RLC数据重传的数量，如果误块较多或重传较多，都会对PS业务的速率产生影响，这种情况大多是因为空口质量差或IUB带宽不足导致；十堰的QOS跟踪显示，上行误块为0（CRCI错误和CRCPAYLOAD错误），下行重传率（下行重传TB/下行TB数）很低，进一步确认速率低和无线环境关系不大。信令过程分析确认：对于十堰路测的信令过程进行分析，有切换过程，但是速率调整过程基本没有，因此PS调度参数设置应该没有问题。消息参数分析确认：分析华为网络的消息参数，十堰消息参数，连云港消息参数，基本一致，并且尝试对RLC窗口和状态报告禁止定时器进行修改，效果不是很明显，但是这些参数在湖南测试，路测有30K提升。因此需要将这些参数沉淀下来。修改的参数见附录1。由于胡乐薇反馈对于decode_int=1时基站存在误判，对应的测量 snr值很低，检查参数配置HsscchBlerTarget，华为为-20，大唐为-60HsscchBlerTargetHS-SCCH Bler目标值-3150-300界面值=100*Lg(实际值)；如BLER=0.001时界面值为-300。【郭俊利】：协议和实际值对应关系：-- Actual value Bler-Target = IE value * 0.05Bler-Target ::=INTEGER (-63..0)配置的是-60，相当于－3，即0.1％另外十堰曾尝试将MAC-D PDU SIZE修改为1032，发现对Ｈ速率有５０Ｋ以上的提升，目前在湖南测试验证。单板处理问题确认：根据客服反馈怀疑ＢＰＯＥ和ＢＰＯＦ的单板处理能力上有差异，因此导致速率不一字，连云港使用ＢＰＯＥ，速率正常，湖南和十堰使用ＢＰＯＦ速率比较低，因此怀疑这两种类型的板卡存在差异，后十堰更换为ＢＰＯＡ进行测试，速率没有提升。全国范围板卡和单线程调研章贵负责中。初步结论：速率低和无线及ＦＴＰ服务器关系不大，并且由于十堰在不切换时小区内移动速率就会有波动，因此更可能和移动情况下数据传输有关。后续定位思路比较连云港速率高十堰速率低，两个城市ＬＯＧ中的差异性；十堰升级基站版本后再测试，并在此基础上基站和RNC研发一起分析数据进行定位。三．如何判断是单线程还是多线程：　　　　下面是４月２６日十堰路测时的一个业务面跟踪转换的ＷＩＲＥＳＨＡＲＫ文件，从文件中可以看到终端(IP:09)请求FTP服务器（IP：2）下载一个８Ｍ的文件，帧号41到43是一个TCP建链的握手过程，在三步握手过程会分配此次FTP下载承载的TCP 连接的终端端口和服务器端口，后续FTP下载都是在这对端口上进行，如果只有一次TCP连接建链过程，整个FTP下载都在这个端口上进行则为单线程，那么就是单线程，如下图，如果建立了多个TCP连接（重复多次图中给出的TCP建链过程，数据在多个端口上传输）用于FTP数据传输，那么就是多线程。四．Wireshark分析简单介绍1．过滤功能，采用这个功能可以对抓取的数据包根据需要进行过滤，比如下面是将源IP地址为06的IP包过滤出来，其它常用的命令还有ip.addr==06：过滤IP地址为06的数据包；TCP.PORT==4032:将所有TCP端口号为4032的数据包过滤出来。2．如果是TCP包，在出现丢包后wireshark会提示“TCP Previous segment lost”，表示在这个包之前的一些包还没有收到，可能已经被丢弃了：比如下面是终端连续收到的三包数据，第一包数据的SN为70081，它的长度是1460，那么它的下一包数据的SN应该是71541，而实际收到的第二包数据的SN是73001，第三包