鼎利软件使用问题(鼎利回复)

上传人:汽*** 文档编号:511349373 上传时间:2023-12-25 格式:DOCX 页数:10 大小:505.63KB
返回 下载 相关 举报
鼎利软件使用问题(鼎利回复)_第1页
第1页 / 共10页
鼎利软件使用问题(鼎利回复)_第2页
第2页 / 共10页
鼎利软件使用问题(鼎利回复)_第3页
第3页 / 共10页
鼎利软件使用问题(鼎利回复)_第4页
第4页 / 共10页
鼎利软件使用问题(鼎利回复)_第5页
第5页 / 共10页
点击查看更多>>
资源描述

《鼎利软件使用问题(鼎利回复)》由会员分享,可在线阅读,更多相关《鼎利软件使用问题(鼎利回复)(10页珍藏版)》请在金锄头文库上搜索。

1、一、 前台软件 Pioneer1. 测试时FTP下载或上传速率低FTP 下载或上传速率低,与网络环境、车速、电脑性能以及使用软件有关。若是怀疑只有鼎利软件做上传、下载速率低,其他软件测试的结果正常,请先按照如下的方法验证一下:1、请选择一个网络信号较好的地点做定点的CQT测试。测试前确保这个扇区只有1个用户。2、拨号上网,不打开前台测试软件,使用类似FLASHXP/WSFTP/CUTEFTP等商用FTP软件,上传或下载一个大于10M的压缩文件,查看一下商用FTP软件上传或下载的速度。连 续测 5 次,取其速率的平均值。R 227 Entering FaEiive Mode (192, 168.

2、 1,2, 12, 15)R正在打开数搏连接IF: 192.168.1.2鑰口: 3087R LIST -alR 150 Opening ASCII mode data coimection for /bin/ls.R 226 Transfer complete.R列表完成:14 KB 用时 0.58 秒 C24.7 KB/S) 饋输甌列已完成已传输1平文件,总计14.78 MB用时3分钟35秒(71. 1 KB/s)空闲.(00:10)3、断开拨号网络,打开Pioneer,在同一个FTP服务器上传或下载同样大小的文件。连续测试5 次,查看其平均速率。4、更换FTP服务器,使用商用FTP软件以

3、及鼎利软件再试一次。注意:1、不要用不同的电脑测试的结果来对比。不同电脑的性能、安装的软件不一样,上 传/下载的速率可能会有很大的差别。因此建议对比测试时采用性能比较好的同一台电脑, 关掉网络防火墙、杀毒软件等其他一些网络软件再进行测试。2、不要使用迅雷等下载软件来做对比测试;3、可以使用 DU METER 等网络流量监控软件实时查看网络流量,但是不要用这个软 件来统计上传/下载的速率(因为这个软件得出的统计结果为所有瞬时速率的平均值,而不 是电信规范要求的上传下载的速度平均值)。如果测试结果显示商用 FTP 软件与鼎利软件相差不大,速度都比较慢,建议卸载一些非测 试所需的网络相关软件,并对电

4、脑做系统的优化。如果测试结果显示商用软件比鼎利软件有较大差距,鼎利软件测的结果较慢,可以尝试以下 解决方法:1、 如果使用的终端是EC226,则请卸载原有的EC226的驱动程序,并安装EC360的驱动。 驱动程序下载地址为: http:/ (SN-KJ2AA)Driver.zip2、经 多 方 查 资 料 , 在 微 软 的 文 档 库 ( MSDN ) 上 有 一 段 说 明 : http:/ EVDO MODEM测试。根据以上说明,我们对注册表进行了修改以适应这种高速测试的C: Documents and 环境。请替换Pioneer安装路径下原有的dll文件。叱SupZs2. 前台或后台软

5、件解码时会报错。1、确保工程所在的的分区内有足够的连续空间(比如若是工程所在路径为 D:ProgramFilesDingLiPilot Pioneer3.6.1.33 20090226,那么就要确保D盘要有足够的连续空间)。2、对工程所在的分区进行磁盘碎片整理,确保这个分区能提供足够的连续空间(开始程 序附件系统工具磁盘碎片整理程序)。3. 测试数据不能合并。使用 ULTRA EDIT 软件打开所需要合并的测试数据,确保这些数据是用同一种终端来 采集的。二、 后台软件 Navigator1. 统计结果显示RLP速率小于应用层速率按照目前的测试规范,当时测试时是采用 60 秒的超时设置,也就是说

6、,差不多每 60 秒就下载一个文件。在每一次下载过程中经过的步骤大概如下:ppp拨号连接,ppp连接成 功,软件开始尝试连接FTP服务器,连接FTP服务器成功,软件尝试从FTP服务器上找到 所要下载的文件,找到文件成功,开始下载第一个字节,下载完成最后一个字节,PPP连接 挂断。应用层速率是从下载第一个字节才开始计算的,到下载完成最后一个字节停止计算。 而RLP从PPP连接就开始有流量了,由于这个时候流量非常小,因此降低了整个RLP的速 率。如果测试时下载的是一个很大的文件,测试时间持续很长,那么由于PPP连接时间以 及FTP服务器连接时间很短,只占用了整个测试时间很小的一部分,RLP的速率就

7、会肯定 大于应用层的速率;正是因为每次下载的时间太短,只有60 秒, PPP连接时间以及FTP服 务器连接时间(包括后来的 PPP 挂断时间)占用了整个测试时间不可忽视的一部分,因此 统计看来RLP速率就比应用层速率低了。RLP 速率比应用层速率低,根本原因在于统计的起始点和终止点不一致。如果大家都 是从应用层下载第一个字节开始计算,到应用层下载完最后一个字节截至,那么 RLP 的速 率也是肯定会比应用层速率大的。我们软件以前就是采取这种方式来统计,但是由于这样的 统计方式与ACTIX不一致,因此后来又改成与ACTIX 致的统计方法了(就是目前的统 计方法)。我们新出的版本会增加新的RLP的字

8、段,来解决RLP速率比应用层慢的问题。RLP 的速率现在的计算方法是:手机每4 秒给出一个总的流量,软件会根据这4 秒的流 量给出一个平均值(也就是说4 秒一个采样点)。举个例子,软件从0 秒开始下载数据,第 4 秒时手机上报了一个流量,那么此时的 RLP 速率就是这个流量/4 ;第八秒的时候又有一个 流量,那么此时的速率就是这个流量/8。也就是说,RLP的速率其实是一个一直在做平均的 平均速率,并不能反应瞬时的情况;而且最后的RLP速率的平均值,也就是将这些平均的 速率再来平均一次。我们觉得这种算法非常不合理,因此我们新的版本会改进这一算法(这样是应电信的要 求,但是这样跟ACTIX又不一致

9、了)。新的算法是这样的:软件会分析手机的流量,给出RLP层每秒的瞬时速率,这样就能 有效的与物理层、应用层的瞬时速率做对比;同时最后计算平均RLP速率的时候,我们的 起止时间也和应用层一样,都是从应用层下载第一个字节开始,到下载完最后一个字节结束。 这样就能保证RLP比应用层的速率大了。我们最新的版本已经解决了这个问题。 http:/ 在这一版本中,我们增加了 RLP瞬时速率的字段EV_RxRLPThrputInstant/EV_TxRLPThrputInstant,这两个参数可以在菜单统计一自定义统计 报表中得到统计结果。我们的统计结果在数据业务上做了过滤。也就是说,这个统计结果是 从数据业

10、务开始测试的时间算起,不计算PPP拨号连接过程中的RLP速率。需要注意的是, 最后的平均值仍然是所有这些瞬时速率的平均。2. 后台统计结果显示RLP速率比DRC申请速率高我们在发现这些问题的地方进行了多次对比验证测试,测试的结果表明我们软件本身解 码并没有问题(用QXDM测试也反映了这一点),详细请参照附件。C:Documents andSettingsSupervisF面用我在现场用QXDM测试的一个例子来说明:1. Instantaneous Throughput(ls)是物理层的瞬时吞吐量,1秒计算一次,在本例中请 求的DRC速率在614.4kbps左右徘徊,而物理层的吞吐量是在1M左右

11、.之所以没有提 RLP速率,是因为在DO网络中,RLP的速率是这么出来的(按照QXDM提供的算法): 从手机刚有流量开始计算,每4秒给出一个流量值。这个流量值是一个累加值,也是从开始 有速率的时候进行累加。也就是说RLP的流量每4秒变一次,越来越大。RLP的速率就是 用这个累加的流量值除以从开始有流量到当前点的时间长度。也就是说, DO 网络的 RLP 速率其实是一个平均速率(1X网络的是瞬时速率),而物理层的是1秒的瞬时速率(算法 是后一秒的流量减去前一秒的流量除以1s),因此要对比的话最好用物理层的瞬时速率来对 比 DRC 速率。2另外通过看图的左上角红框中传输的CRC的块来看,请求的DR

12、C7是最多的, DRC7的最高速率614kbps,而事件物理层的速率是大于请求的;附件文档解释得非常清 楚.在无线网络质量很好的情况下,完全不需要用完所有的请求的时隙就传输完成了,DR C请求只是手机终端根据测量的C/I来估算的,这样的估算都会给出一些余量,所以请求 的速率一定要大于实际速率的在EVDO网络中是不正确的.3. 应用层最大瞬时速率非常大,超过了理论值这是因为电脑缓存的原因造成的。FTP瞬时速率的生成是按照First data时刻点来算的, 那时由于缓存里面已经下载了部分数据,但计算时间太短,因此导致出现大值。这跟商用软 件的做法是一样的。4. 后台软件如何得出PING时延的区间分

13、布表目前我们的后台软件还不能直接统计出PING时延的区间分布,但是可以得到每次PING的时延。区间分布表可以使用这个结果来手工计算一下。逞F护聲樓FTPPtSi我们最新的版本已经解决了这个问题。http:/ 后台软件统计显示分组业务掉话率非常高通过查看后台软件的事件窗口,我们可以得知绝大多数分组业务掉话是由于超时所致。嗡 Event Details - CDMA2 0308-160618-lOlSearch |PPP DialEventTimeMessageEVDO Reserve SoftHandoff.EVDO Virtual SoftHandoffSu.EVDO Virtual Soft

14、Handoff Su.EVDO connection ClosePPP Dial HangupPPP DialFTP Download兰 FTP Download Connect 福 FTP Download Send RETR 站 FTP Download First Data 伶 EVDO Reserve SoftHand. 詹 EVDO Reserve SoftHand.16:09:29:51516:09:29:32816:09:30:10916:09:32:78116:09:33:06216:09:47:64016:09:53:45316:09:53:45316:09:54:62516:09:57:67116:10:22:93716:10:23:000NR UP TrafficCDMAEV-MCDMA1xEV-ENCSP ConnecCDMA1xEV- ICDMAIxEV-CDMA1xEV-ECDMA1xEV-ECDMA1xEV-ECDMA1kEV-NRUP TrafficNRUPTraffict於 EVDO Reserve SoftHand. 16:10:30:687 NRUP TraffictEVDO Reserve SoftHand. -尸歯 FTP Download DropTime: 56(s)16:10:30:687 NRUP

展开阅读全文
相关资源
正为您匹配相似的精品文档
相关搜索

最新文档


当前位置:首页 > 学术论文 > 其它学术论文

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号