得到结果
当TTCP发送者完成发送 所有其数据，两边将打印吞吐量统计数据并且终止。在这种 情况下，IOS TTCP发送者显示：
ttcp-t: buflen=8192, nbuf=50, align=16384/0, port=5001 tcp ->
10.1.1.52 ttcp-t: connect (mss 1460, sndwnd 4096, rcvwnd 4128) ttcp-t: 409600
bytes in 84544 ms (84.544 real seconds) (~3 kB/s) +++ ttcp-t: 50 I/O calls
ttcp-t: 0 sleeps (0 ms total) (0 ms average)
PC TTCPW接受器另一方面，显示：
ttcp-r:
409600 bytes in 8
4.94 seconds = 4.71 KB/sec
+++ ttcp-r: 79 I/O calls, msec/call = 1101.02, calls/sec =0.93
这时，您可以想要采取调制解调器或端口可操作状态 的另一个快照。此信息是否可以是有用在分析期间检查例如 ，调制解调器连接体验所有再培训或速度转换。
分析结果
因为它是最普通宁可评 估连接速度在kbps (千位每秒或者1000比特每秒)该Kbps (千字节每 秒或者1024个字节每秒)，我们必须使用信息从TTCP计算比特率(在 kbps)。使用接收的字节数和转发时间计算实际比特率为连接 。
计算比特率通过转换字节数成位 然后分开此当对于转移的时候。在本例中，窗口PC在84.94秒 接受了409600个字节。我们能计算比特率(409600个字节*每 个字节8位)由84.94 seconds=38577 BPS或38.577 kbps分开。
注意 接收器侧 结果是轻微更加准确的，因为发射机也许认为完成在之后执行为时 写-即，在数据实际上横断了链路之前。
相对45333个BPS的名义上链路速度(确定从 show modem operational-status 命令)，这是一张85%效率。这样的效率是产生的正常 link access procedure for modems (LAPM)，PPP、IP和TCP头开销 。如果结果是显着与什么不同您期待，分析操作状态、调制 解调器日志和，如果需要，客户端调制解调器统计数据发现什么可 以有发生在影响性能(例如EC转播，速度转换、再培训等等云云。
执行上行链路测试(从Windows PC到路由器)
其次，执行一个上行吞吐量测试。 这与下行 链路测试是相同的，除了Cisco IOS TTCP作为接受器，并且 Windows TTCPW是发射机。 首先，设置路由器作为接受器， 使用默认参数：
customer-dialin-sj>ttcp
transmit or receive [receive]:
perform tcp half close [n]: use tcp driver [n]: receive buflen [8192]: bufalign
[16384]: bufoffset [0]: port [5001]: sinkmode [y]: rcvwndsize [4128]: delayed
ACK [y]: show tcp information at end [n]: ttcp-r: buflen=8192, align=16384/0,
port=5001 rcvwndsize=4128, delayedack=yes tcp
激活PC作为TTCP发射 机并且指定路由器的IP地址。参见README文件带有窗口TTCP 软件为适当的语法：
C:\PROGRA~1\
TTCPW>ttcpw -t -s -n 50 10.1.1.1 ttcp-t:
buflen=8192, nbuf=50, align=16384/0, port=5001 tcp -> 10.1.1.1 ttcp-t:
socket ttcp-t: connect
IOS接受器报告 以下结果：
ttcp-r: accept from 10.1.1.52 (mss 1460, sndwnd 4096, rcvwnd
4128) ttcp-r:
409600 bytes in 23216 ms (23.216 real seconds)
(~16kb/s) +++ ttcp-r: 280 I/O calls ttcp-r: 0 sleeps (0 ms total) (0 ms average)
这出来作为上行吞吐量 141144个BPS -或几乎6:1压缩速率相对24 kbps的名义上上行速率。这是考虑硬件压缩的一个有趣结果失效(我们确定从 show modem operational-status)。 然而，使用IOS命令 show compress证实是否使用任何。
总指导大纲
这是一些总指导大纲为使用TTCP测量IP 路径吞吐量：
为有意义的结果，运行TTCP的主机应该有大量CPU电源相对链路速度 。这是真的当链路是45 kbps时并且主机是空闲AS5300和 700MHz PC。这不是真的如果链路是100baseT 并且其中一台 主机是Cisco 2600路由器
Cisco IOS 对待路由器来源的数据与通过路由器路由的数据不同。在我 们的上面的例子，虽然微软点到点压缩(MPPC)压缩在链路协商在测 试之下，路由器传输的数据没有使用软件压缩，而PC传输的数据。 这就是为什么上行吞吐量显着大于downlink吞吐量。 对于性能测试高带宽链路，您应该 通过 路由器 总测试。
为IP路径带有大带宽*延迟产品，它 是重要使用TCP窗口大小满足保持管道充分。 一旦调制解调 器链路，默认值4 KB窗口大小正常是足够的。您能提高 IOS TCP窗口大小与命令i p tcp窗口大小。参见非IOS系统的适当的说明文件 。
另一个简单的方法测试吞吐量横 跨调制解调器链路将使用开放源工具 Through-putter 。在 网络服务器上安装此工具在接入服务器之后并且让Windows PC客户 端使用浏览器召集Java工具。在调制解调器连接可能然后用 于它迅速确定数据速率。是开放源工具和Cisco技术支持中心 不支持此调制解调器吞吐量附属程序。 参见README文件带有 进一步安装和操作说明书的工具。
| 共2页: 上一页 [1] 2 | ||
|
相关文章
