之前在国外的测试团队发回报告说，我们的产品（DL7.2M/UL2M）比另一款对比机（DL3.6M/UL2M）的下载速度要慢许多，还给了我们几组对比数据。一看，我们的速率只有别人的几分之一。这可是个大问题啊，产品的最大卖点都成最大缺点了。后来他们又发邮件说，他们之前的报告中有笔误，Kbps写成KBps了。两个单位有8倍的换算关系，难怪我们的速率只有别人的几分之一。虚惊一场！不过也是有存在一些问题的，就是我们的速率不稳定，忽高忽低。造成的结果是，下载同样大小的文件，需要的时间比其它产品多。
一、分析UMTS下的网络速率可以用QXDM的一些工具（用QXDM分析物理层速率似乎只能用于UMTS下，GSM下还没发现有对应的工具），如下所示：
1）WCDMA EUL Link Statistic:
这个工具可以查看的信息很多，每个信息都有两组数据，分别是上一秒的数据和总的平均数据。
2）WCDMA HSDPA Decoding Statistic:
这个工具可以查看每个传输块大小对应的误码率（BLER）等信息，有一个很重要的信息是，物 理层的传输速度（列表框下的第二栏数据）。
3）WCDMA HSDPA Link Statistic:
这个工具可以用于动态地查看传输速率的变化情况，主要是从整体上来观察（因为上面的信息是动态变化的，而且速度比较快，一般用来查看宏观的信息）。可以在QXDM中右击菜单里把"Cursor"勾上，然后把中间的黄色竖线拉到最右边，这样右上角的信息会动态显示当前的一些值。
虽然这次并不是真的速率上出了问题，但如果速率上出了问题，可以检查以下的几个方面：
1）CQI值
2）HS_SCCH
3）TCP Window Size and MSS (MTU) －－可以参考文档80-VF064-1_C_Rec_Param_Settings_Thruput_Num_HSDPA_HSUPA.pdf里的推荐配置
二、如果用QXDM查看到物理层的传输速率正常，那可以用Ethereal/Wireshark抓包来分析（这跟无线网络无关，纯属Internet协议，所以UMTS和GSM下都可以）是否是上层应用的问题，如TCP/IP包本身出了问题。
下载过程中会有很多这样的包：
......
347 01:35:03.706054 82.94.164.162 10.11.230.200 TCP [TCP segment of a reassembled PDU]
-->查看解析后的数据：
@1: Window Size : 6432 （这个值跟TCP segment data size有何关系？）
@2: TCP segment data (1460) --> 看值是否为1460，一般1460为最佳传输大小，小于这个值可能造成速率低
@3: [The RTT to Ack the segment was : 0.059570000 seconds] --> RTT表示发送端发送数据包到接收到响应的时间（Round-Trip Time），这个值越大，说明响应越慢，也会造成速率低。
@4: 是否经常有包被重发（这里没有相应的例子作说明），包被重发也会影响速率。
348 01:35:03.706054 10.11.230.200 82.94.164.162 TCP sweetware-apps > http [ACK] Seq=492 Ack=286161 Win=17520 Len=0
-->这是Ack包。这个包比较有用的信息应该也是RTT。不过似乎Ack消息包含的信息有好几种（不管哪种ACK都会包含"This is an Ack to the segment in frame: xxx"的信息），具体可以看一下包的解析。
......
Ethereal/Wireshark解析出的信息非常丰富，除了以上提到的信息只不过是TCP层的其中一部分。
三、（对数据卡而言）串口的通讯速率：
以下引自微软的官方网站：
“该速度代表程序向调制解调器传输数据的最大速度，通常比调制解调器的速度快。例如，对于 33.6 Kbps (V.34) 的调制解调器，通常设为 57,600 bps。
更改此设置的同时也设置了调制解调器当前的速度。要将当前速度更改为其他值，请参阅“相关主题”来了解更改数据连接首选项的过程。”
这是很容易被忽略的一点。默认的串口（modem）通讯速率一般是115200bps，对于DL7.2M/UL2M的modem，最大端口速度要比这个值大，以免成为传输瓶颈。
没有评论:
发表评论