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

一、前台软件Pioneer测试时FTP下载或上传速率低FTP下载或上传速率低，与网络环境、车速、电脑性能以及使用软件有关。若是怀疑只有鼎利软件做上传、下载速率低，其他软件测试的结果正常，请先按照如下的方法验证一下:1、请选择一个网络信号较好的地点做定点的CQT测试。测试前确保这个扇区只有1个用户。2、拨号上网，不打开前台测试软件，使用类似FLASHXP/WSFTP/CUTEFTP等商用FTP软件，上传或下载一个大于10M的压缩文件，查看一下商用FTP软件上传或下载的速度。连续测5次，取其速率的平均值。[R]227EnteringFaEiiveMode(192,168.1,2,12,15)[R]正在打开数搏连接IF：鑰口：3087[R]LIST-al[R]150OpeningASCIImodedatacoimectionfor/bin/ls.[R]226Transfercomplete.[R]列表完成：14KB用时0.58秒C24.7KB/S)饋输甌列已完成已传输1平文件，总计14.78MB用时3分钟35秒(71.1KB/s)空闲.(00:10)3、断开拨号网络，打开Pioneer，在同一个FTP服务器上传或下载同样大小的文件。连续测试5次，查看其平均速率。4、更换FTP服务器，使用商用FTP软件以及鼎利软件再试一次。注意:1、不要用不同的电脑测试的结果来对比。不同电脑的性能、安装的软件不一样，上传/下载的速率可能会有很大的差别。因此建议对比测试时采用性能比较好的同一台电脑，关掉网络防火墙、杀毒软件等其他一些网络软件再进行测试。2、 不要使用迅雷等下载软件来做对比测试；3、 可以使用DUMETER等网络流量监控软件实时查看网络流量，但是不要用这个软件来统计上传/下载的速率（因为这个软件得出的统计结果为所有瞬时速率的平均值，而不是电信规范要求的上传下载的速度平均值）。如果测试结果显示商用FTP软件与鼎利软件相差不大，速度都比较慢，建议卸载一些非测试所需的网络相关软件，并对电脑做系统的优化。如果测试结果显示商用软件比鼎利软件有较大差距，鼎利软件测的结果较慢，可以尝试以下解决方法:1、如果使用的终端是EC226,则请卸载原有的EC226的驱动程序，并安装EC360的驱动。驱动程序下载地址为:/download/driver/Huawei%20EC360（SN-KJ2AA）Driver.zip2、 经多方查资料，在微软的文档库（MSDN）上有一段说明:/kb/246984/zh-cn,也就是说默认的8K缓冲区大小可能不适合EVDOMODEM测试。根据以上说明，我们对注册表进行了修改以适应这种高速测试的C:\Documentsand环境。请替换Pioneer安装路径下原有的dll文件。 叱\SupZs前台或后台软件解码时会报错。1、 确保工程所在的的分区内有足够的连续空间（比如若是工程所在路径为D:\ProgramFiles\DingLi\PilotPioneer320090226，那么就要确保D盘要有足够的连续空间）。2、 对工程所在的分区进行磁盘碎片整理，确保这个分区能提供足够的连续空间（开始—程序—附件—系统工具—磁盘碎片整理程序）。测试数据不能合并。使用ULTRAEDIT软件打开所需要合并的测试数据，确保这些数据是用同一种终端来采集的。二、后台软件Navigator统计结果显示RLP速率小于应用层速率按照目前的测试规范，当时测试时是采用60秒的超时设置，也就是说，差不多每60秒就下载一个文件。在每一次下载过程中经过的步骤大概如下：ppp拨号连接，ppp连接成功，软件开始尝试连接FTP服务器，连接FTP服务器成功，软件尝试从FTP服务器上找到所要下载的文件，找到文件成功，开始下载第一个字节，下载完成最后一个字节,PPP连接挂断。应用层速率是从下载第一个字节才开始计算的，到下载完成最后一个字节停止计算。而RLP从PPP连接就开始有流量了，由于这个时候流量非常小，因此降低了整个RLP的速率。如果测试时下载的是一个很大的文件，测试时间持续很长，那么由于PPP连接时间以及FTP服务器连接时间很短，只占用了整个测试时间很小的一部分，RLP的速率就会肯定大于应用层的速率；正是因为每次下载的时间太短，只有60秒,PPP连接时间以及FTP服务器连接时间（包括后来的PPP挂断时间）占用了整个测试时间不可忽视的一部分，因此统计看来RLP速率就比应用层速率低了。RLP速率比应用层速率低，根本原因在于统计的起始点和终止点不一致。如果大家都是从应用层下载第一个字节开始计算，到应用层下载完最后一个字节截至，那么RLP的速率也是肯定会比应用层速率大的。我们软件以前就是采取这种方式来统计，但是由于这样的统计方式与ACTIX不一致，因此后来又改成与ACTIX—致的统计方法了（就是目前的统计方法）。我们新出的版本会增加新的RLP的字段，来解决RLP速率比应用层慢的问题。RLP的速率现在的计算方法是:手机每4秒给出一个总的流量，软件会根据这4秒的流量给出一个平均值（也就是说4秒一个采样点）。举个例子，软件从0秒开始下载数据，第4秒时手机上报了一个流量，那么此时的RLP速率就是这个流量/4；第八秒的时候又有一个流量，那么此时的速率就是这个流量/8。也就是说，RLP的速率其实是一个一直在做平均的平均速率，并不能反应瞬时的情况；而且最后的RLP速率的平均值，也就是将这些平均的速率再来平均一次。我们觉得这种算法非常不合理，因此我们新的版本会改进这一算法（这样是应电信的要求，但是这样跟ACTIX又不一致了）。新的算法是这样的：软件会分析手机的流量，给出RLP层每秒的瞬时速率，这样就能有效的与物理层、应用层的瞬时速率做对比；同时最后计算平均RLP速率的时候，我们的起止时间也和应用层一样，都是从应用层下载第一个字节开始，到下载完最后一个字节结束。这样就能保证RLP比应用层的速率大了。我们最新的版本已经解决了这个问题。/download/Navigator%20setup%20for%20EVDO.zip在这一版本中，我们增加了RLP瞬时速率的字段EV_RxRLPThrputInstant/EV_TxRLPThrputInstant,这两个参数可以在菜单统计一自定义统计报表中得到统计结果。我们的统计结果在数据业务上做了过滤。也就是说，这个统计结果是从数据业务开始测试的时间算起，不计算PPP拨号连接过程中的RLP速率。需要注意的是,最后的平均值仍然是所有这些瞬时速率的平均。后台统计结果显示RLP速率比DRC申请速率高我们在发现这些问题的地方进行了多次对比验证测试，测试的结果表明我们软件本身解码并没有问题（用QXDM测试也反映了这一点），详细请参照附件。C:\Documentsand

Settings\SupervisF面用我在现场用QXDM测试的一个例子来说明:1.InstantaneousThroughput（ls）是物理层的瞬时吞吐量，1秒计算一次，在本例中请求的DRC速率在614.4kbps左右徘徊，而物理层的吞吐量是在1M左右.之所以没有提RLP速率，是因为在DO网络中，RLP的速率是这么出来的（按照QXDM提供的算法）：从手机刚有流量开始计算，每4秒给出一个流量值。这个流量值是一个累加值，也是从开始有速率的时候进行累加。也就是说RLP的流量每4秒变一次，越来越大。RLP的速率就是用这个累加的流量值除以从开始有流量到当前点的时间长度。也就是说，DO网络的RLP速率其实是一个平均速率（1X网络的是瞬时速率），而物理层的是1秒的瞬时速率（算法是后一秒的流量减去前一秒的流量除以1s），因此要对比的话最好用物理层的瞬时速率来对比DRC速率。2•另外通过看图的左上角红框中传输的CRC的块来看，请求的DRC7是最多的,DRC7的最高速率614kbps，而事件物理层的速率是大于请求的；附件文档解释得非常清楚.在无线网络质量很好的情况下，完全不需要用完所有的请求的时隙就传输完成了，DRC请求只是手机终端根据测量的C/I来估算的，这样的估算都会给出一些余量，所以请求的速率一定要大于实际速率的在EVDO网络中是不正确的.

应用层最大瞬时速率非常大，超过了理论值这是因为电脑缓存的原因造成的。FTP瞬时速率的生成是按照Firstdata时刻点来算的,那时由于缓存里面已经下载了部分数据，但计算时间太短，因此导致出现大值。这跟商用软件的做法是一样的。后台软件如何得出PING时延的区间分布表目前我们的后台软件还不能直接统计出PING时延的区间分布，但是可以得到每次PING的时延。区间分布表可以使用这个结果来手工计算一下。

逞 F护聲樓 FTPPtSi逞 F护聲樓 FTPPtSi我们最新的版本已经解决了这个问题。/download/Navigator%20setup%20for%20EVDO.zip5.后台软件统计显示分组业务掉话率非常高通过查看后台软件的事件窗口，我们可以得知绝大多数分组业务掉话是由于超时所致。嗡EventDetails-嗡EventDetails-CDMA20308-160618-lOlSearch|PPPDialEventTimeMessageEventTimeMessageEVDOReserveSoftHandoff...EVDOVirtualSoftHandoffSu...EVDOVirtualSoftHandoffSu...EVDOconnectionCloseEVDOReserveSoftHandoff...EVDOVirtualSoftHandoffSu...EVDOVirtualSoftHandoffSu...EVDOconnectionClosePPPDialHangupPPPDialFTPDownload兰FTPDownloadConnect福FTPDownloadSendRETR站FTPDownloadFirstData伶EVDOReserveSoftHand...詹EVDOReserveSoftHand...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:000NRUPTraffic^CDMA^EV-MCDMA1xEV-ENCSPConnecCDMA1xEV-[ICDMAIxEV-™CDMA1xEV-ECDMA1xEV-ECDMA1xEV-ECDMA1kEV-[NRUPTrafficNRUPTraffict於EVDOReserveSoftHand...16:10:30:687NRUPTraffictEVDOReserveSoftHand...EVDOReserveSoftHand...-尸歯FTPDownloadDropTime:56(s)16:10:30:687NRUPTraffic16:10:53:515CDMA1kEV-[ActualSize:12029480(...Reason:TimeOutFTPDownloadDisconnect16:10:53:578CDMA1xEV-EEVDOconnectionClose16:11:03:671NCSPConnerPPPDialHangupPPPDial16:11:03:953CDMA1xEV-EEVDOconnectionClose16:11:03:671NCSPConnerPPPDialHangupPPPDial16:11:03:953CDMA1xEV-E16:11:10:593CDMA1mEV-EEVDOReserveSoftHandoff...16:11:24:281NRUPTraffictEVDOReserveSoftHandoff...16:11:24:281NRUPTrafficFTPDownloadEVDOVirtualSoftHandoffSu...FTPDownloadEVDOVirtualSoftHandoffSu...16:11:24:453CDMA1xEV-E16:12:26:093CDMA1xEV-L由规范可以看到，测试过程中我们需要下载一个很大的文件，并且上传/下载的市场要设为60秒。也就是说，如果60秒内不能完成一次上传/下载，软件就会自动挂断本次PPP连接，并且记为一次PPP的掉线。因此，统计时应该把这些掉线原因为超时（timeout）的事件去掉，或者是在测试时将测试模板的超时设置设长。TemplateConfiguration:[qwe]xj斥FTPPPPDialServerConfigHost|14jJUserNameqwe由规范可以看到，测试过程中我们需要下载一个很大的文件，并且上传/下载的市场要设为60秒。也就是说，如果60秒内不能完成一次上传/下载，软件就会自动挂断本次PPP连接，并且记为一次PPP的掉线。因此，统计时应该把这些掉线原因为超时（timeout）的事件去掉，或者是在测试时将测试模板的超时设置设长。TemplateConfiguration:[qwe]xj斥FTPPPPDialServerConfigHost|14jJUserNameqwePasswordI-Anonymous两PassiveFilesConfigDownloadFilel/SOMElDL.rarDirforDownloads|DAProgramFiles\DingLi\PilotPioneer3.6.1PeerDirectory|UploadFile[91919191Timps：|l0咄J71TimeOut(s)160000IntervaInfinite^BinaryMode两DownloadThreadCount|3FTPBuffer(byte)5120CASCIIMode两Disconnectevervtime厂TCP/IPMonitorI-UploadXCancel我们最新的版本已经解决了这个问题。/download/Navigator%20setup%20for%20EVDO.zip6.后台软件统计显示下载/上传的速度为空由于采用电信新的规范60秒超时的设置来测试，导致很多下载/上传不能完成。而按照电信的规范，这种没有完成的数据是不参与统计的，因此后台统计结果为空。我们的前台软件考虑到了这种情况，因此建议用前台软件来统计这类速率（统计—选择数据）FTPDownllo