Throughput_troubleshooting.txt

==Preparetion==
Reliance-M项目上理想的下行数据吞吐量应该是在95Mbps。

在无线数据传输中，引起数据吞吐量差异的原因有很多，例如最明显的就是手机的RF各项参数未校准，当然还有很大一部分问题就需要分析所在地的网络环境，根据能够测量的各项网络状态参数，判断问题根源是否出在网络端，最后当然还有手机自身的原因。

在分析这些网络反馈的测量数据时，我们可以用到qxdm，wireshark这些工具，在qxdm中可以通过抓取的log观察到物理层的数据速率以及BLER情况。(误块率，不同BER误码率，误块率检测对象是已经经过交织、速率匹配、信源解码、CRC等一系列过程后的语音块数据，而BER检测只是单纯的数据流，在用途上，BER是用来衡量接收机特性的指标，而BLER是用来衡量系统性能测试的，也就是说并不是说只有载频故障才会导致BER差，BER高的原因有很多，例如载波硬件故障或内部设备的非线性元件引起的噪音干扰或者外部的同/邻频干扰，也不能排除射频部分器件的非线性引起的噪声或者干扰可能)

如下是qxdm中常用来检测物理层速率的两个view窗口
LTE ML1 DL Throughput and BLER
LTE ML1 UL Throughput and BLER

利用wireshark工具可以在log中看到TCP/IP层的速率以及数据包的发送接收情况

DU meter工具可以监测PC端口的速率

==排查步骤==
1.根据已知的目标速率值，在相同网络环境下，找一个对比机一起进行测试
2.利用wireshark工具查看应用层数据(TCP/IP/HTTP)速率符合标准，是否有TCP包丢失或者数据包重传的现象
3.如果应用层有较多丢包，则检查data-services层的丢包情况，否则就继续检查底层(RLC/MAC/PHY)
4.利用ping命令检查RTT时延
5.使用iperf工具对低层进行UDP测试确定底层带宽是否足够

Details:
1.对比机的速率是否达到标准，不满足则检查网络和测试仪器是否正常。
2.data-call类型是否是"USB-Tethering"？QMI/CM的速率是否达标？都满足则为AP端问题，只满足前者则是modem侧问题，都不满足结束分析过程。
3.若为AP侧问题，通过设置CPU为performance模式、暂停thermal-engine、调整linux-TCP/IP参数判断问题原因是硬件散热/android-data/CPU运行主频问题。
4.若为modem侧问题，通过qxdm检查上下行物理层速率，MAC-PDU(0xB064)的padding(若出现大量padding，检查FTP/UDP服务器，上行传输数据量是否与实际不符)，wireshark工具检查上下行的重传丢包情况。
5.RF性能部分，RF参数的校准，modem RF性能的检查是否通过，若不通过则需要新的修改或patch。
6.case分类：LTE物理层问题(RSRP/RSRQ/BLER/CQI)--LTE/AS; PDCP/RLC/MAC问题--LTE/Data-throughput; 其他的--LTE/Modem-data

==Data services层分析==
Wireshark工具分析部分：
1.Log在wireshark上的速率不应该比DU meter低，否则请检查USB驱动/TCP设置或PC或者工具本身。
2.在wireshark工具里打开PCAP的log，在"statistics--Summary/IO Graphs"中可以看到数据速率的快慢和波动情况。
3.在IO graph里可以利用filter同时显示多各情况的对比曲线。
4.TCP协议下的log里，每一次报文都有对应seq序列号和ACK信息，每一次具体下行TCP数据包都会有对应的ACK报文。
	响应信息的ACK值应该和原信息的ACK值一致。
	"TCP Previous segment lost"，出现包丢失情况，重发消息的seq值和原消息一样
	最后ACK消息对应的ACK值 = 提示TCP包丢失的信息的seq值 + (提示TCP包丢失的信息的seq值 - 原消息/重发消息的seq值)
5.DupACKs和快速重传，快速重传可以较快地恢复TCP流量，保持数据吞吐量在较高传输水平。
	当发送端收到连续三个重复的ACK信息，立即重传该消息ACK对应的TCP报文，将ssthresh降为tx_win值的一半，之后再慢慢恢复到原值大小。
	"TCP Dup ACK xxxx#1"
	"TCP Dup ACK xxxx#2"
	"TCP Dup ACK xxxx#3"
6.通过"分析"中的"专家信息"快速寻找TCP的丢包/重传信息

QXDM工具分析部分：
1.Um-watermark流控分析主要可以参考缓存RLC和PS之间的数据包，Rm-watermark流控参考缓存PS和SIO/SMD之间的数据包，流程频繁启动出现可能会导致数据速率下降。
2.在QXDM-log里根据关键词观察是否有流控频繁启动的现象，根据启动流控的mask值可以找到对应是哪一个模块启动的流控。
	//在disable flow后PS将不能把数据送到Um-Watermark。
	"disabling flow|enabling flow"
	//检查是否出现Watermark消息已满的情况
	"WM full,freeing packet"

==LTE层分析==
通过qxdm的ML层及BLER分析窗口，可以观察到详细的物理层数据速率变化情况。
LTE ML1 DL Throughput and BLER
LTE ML1 UL Throughput and BLER

1.一般TCP/IP层丢包可能性比较大，MAC/RLC/PDCP层出问题概率较小
2.在载波聚合的频带内，会有Pcell和Scell的测量数据。
	pcell和scell都属于同一个eNodeB
3.0xB16C LTE DCI information report
包含一些DCI的记录信息，编码调制方式(QPSK)，不同的调制方式对应着不同的CQI等级，不同的编码速率和频谱利用率。
4.0xB172 LTE PDSCH stat indication | 0x1B173 LTE uplink PKT build indication
物理下行共享信道的状态信息指示 | 上行链路数据包构建指示

测量SINR->内部算法映射SINR到CQI->内部算法映射CQI到TBS->TBS映射到MCS->根据业务量确定PRB数
在LTE中，CQI是4bit，取值范围0-15(0保留，1-6是QPSK，7-9是16QAM，10-15是64QAM)。
(1)下行MCS：0-9  QPSK   10-16  16QAM   17-28 64QAM   29—31保留
       TBS：0-9         9-15           15-26
(2)上行MCS：0-10 QPSK   11-20  16QAM   21-28 64QAM   29—31保留
       TBS：0-10        10-19          19-26
TBS=transport block subpacket

5.LTE LL1 PUCCH CSF 上行物理控制信道 | LTE LL1 PUSCH CSF 上行物理共享信道

6.0xB063/0xB064 LTE MAC UL/DL transport block 上下行传输块

7.0xB0B3/0xB0A3 PDCP层上下行加密数据PDU

==实际情况==
在RFSW的代码中，如果擅自修改射频模块时序的对应代码(提前了打开天线发射/接收通路的时间)，可能会引起速率下降。
原则上来说设备的时序不需要调整，如果需要客制化也尽量将改动控制在2个单位内，而且每次修改后必须做回归测试验证速率没有严重影响。

notch-filter：消除特定频率的干扰，使手机的灵敏度提高，但不恰当的值会抑制下行信号，而使下行速率降低。必要的时候可以移除这些NV再测试下行速率大小。
 RFNV_LTE_C0_SPURS_TABLE_I
 RFNV_LTE_C1_SPURS_TABLE_I
 RFNV_LTE_C2_SPURS_TABLE_I
 RFNV_LTE_C3_SPURS_TABLE_I
 RFNV_WCDMA_C0_SPURS_TABLE_I
 RFNV_WCDMA_C1_SPURS_TABLE_I
 RFNV_TDSCDMA_C0_SPURS_TABLE_I
 RFNV_TDSCDMA_C1_SPURS_TABLE_I

==Log capture==
PC侧的Pcap-log是通过wireshark监测对应的接口获取的。
Android上的Pcap-log直接通过在adb上运行tcpdump即可抓取rmnet/wlan设备的log：adb shell tcpdump -i any -s 0 -w /data/tcpdump.pcap
Qxdm的log可以通过工具转换为Pcap-log

DPL-log
利用qxdm工具抓取Log--Common--Data services--Data protocol logging

Ping命令快速检测链路是否正常，看到环回时延RTT。
ping URL -t ...

UDP及iperf测试
UDP即用户数据包协议，无对端应答的ACK机制，可以指定任意带宽发送数据流，没有其他多余的流程机制。常用与iperf工具灌包测试验证物理信道带宽是否足够，
iperf工具的使用可参考-->80-N2363-1
根据测试是前向链路或者是后端链路，client和server分别在不同的终端上。
iperf -s -u -i 1 (server端，udp协议，信息打印间隙1s)
iperf -c ip-addr -u -b 3M -t 30 --i 1 (client端，ip地址，udp协议，带宽3M，测试时间30s，信息打印间隙1s)
(安装直接下载iperf工具，运行即可，Android环境的话直接将其push到/etc目录下即可，不过我看现在iperf官网上基本都有对应Android的app，直接用app应该还更方便一点，但是都必须要在google play里才能安装有点麻烦)

CPU默认运行在on-demand模式，CPU会动态调整频率。
在进行数据测试时可以将CPU调整为Performance模式，把温控等进程关掉，不过这仅在测试中使用。
adb root
stop mpdecision/thermal-engine //停止这两个进程

echo 1 > /sys/devices/system/cpu/cpu*/online  //设置相应cpu核心为online模式，通常手机运行时不会所有核都处于online状态
echo "performance" > /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor  //设置相应cpu核心为performance模式，设置以后可以在对应的节点查看是否设置成功

cat /sys/class/thermal/thermal_zone*/temp  //获取CPU温度

cat /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq  //获取CPU频率

adb-log中cpu关键词：CPU - Setting CPU[0] to 384000(CPU频率在384MHz，过低); Sensor:tsens_tz_sensor3:61000mC(sensor3的温度在61摄氏度，过高);

top -d 1 -n 5  //检查CPU的利用率大小
mpstat 2 30    //每隔2s打印一次CPU利用率

===SBL===
不同于LK，SBL中会禁用掉所有的debug信息打印，为的是在商用的客户端中终端性能的最优，同理在测试理想数据速率时，也需要使用SBL作为bootimg。

如何使编译出的bootimg是SBL对应的呢？

方法一：
Modify：device/qcom/msmXXX/AndroidBoard.mk
//将"_defconfig"改为"perf_defconfig"
KERNEL_DEFCONFIG:= msm8916-perf_defconfig (MSM8939/MSM8916 32-bit)
make KERNEL_DEFCONFIG=msm-perf_defconfig (MSM8939/MSM8916 64-bit)

方法二：
在编译时，把参数"kernel_defconfig=msmXXXX-perf_defconfig"作为编译参数
make KERNEL_DEFCONFIG=msm8916-perf_defconfig (MSM8939/8916 32-bit)
make KERNEL_DEFCONFIG=msm-perf_defconfig (MSM8939/MSM8916 64-bit)

烧录方法：
在bootloader中，利用"cd path to secondary-boot directory"进入到SBL的烧写路径，然后利用fastboot烧写即可"fastboot flash boot boot.img"




















--------
眼光放在不切实际的东西上是不可以的，你需要看到的是你现在已经有的东西。
所谓心事，不过是不如己意，那就是我沉迷在自己的幻想中，回到现实，一有落差，即生烦恼。