前言 您能使用测试TCP程序 (TTCP)通过IP路径测量TCP吞吐量。使用它，发动接受器在路 径的一端，然后开始发射机在另一边。 传输端寄发TCP信息 包的指定的编号到接收端。在测试的末端，双方显示传输的 字节数并且时间流逝为了信息包能从一端消磨对其他。您在 链路能然后使用这些图计算实际吞吐量。关于概要关于TTCP ，参见 测试与TTCP的网络性能 。
TTCP程序可以是有效的在确定一个特定的广域网或调制解调 器连接的实际比特率。 然而，您能也使用此功能测试连接速 率在任何二个设备之间带有他们的之间IP连通性。
在您开始之前
惯例
欲 知关于文件惯例的更多信息，请参阅 技 术提示惯例。
前提 本文的读者应该是熟知 的下列：
TTCP要求® IOS软件版本11.2 以上和功能集IP Plus (是 镜象)或服务提供商(p- 镜象)。
注 意： ttcp 命令是 一个隐藏的，不支持，特权模式命令。同样地，其可用性可 能从一个Cisco IOS 软件版本变化到另一个，这样在一些版本也许 不存在。
客户端的TTCP软件是可得到 从 /; ttcpw.zip 为客 户端。
使用的组件 本文不限于特定软件和硬件版本。
准备TTCP会议 保证有在测试涉及的二 个设备的之间IP连通性。
并且安 装非IOS客户端的TTCP软件如果需要。
在如下所示的示例，我们设法确定一个调制解调器连 接的连接速率微软视窗PC和AS5300接入的之间。即使 这里包括的许多题目和解释是特定的对调制解调器连接，TTCP程序 可以使用在任何二个设备之间。
使 用 show modem operational-status命令(调制解调器链路)检查连接参数。为其他LAN或广域网方案，此步骤不是必要的。
customer-dialin-sj>
show modem operational-status 1/51 Parameter
#1 Connect Protocol: LAP-M Parameter #2 Compression:
None ...
!--- Output omitted
... Parameter #8 Connected Standard:
V.90 Parameter #9 TX,RX Bit Rate:
45333,24000
此编辑的输出表示，客户端在V.90联系以一种 45333 bps downlink费率和24000 BPS上行速率。 数据压缩 在客户端调制解调器禁用。 因为TTCP测试模式是高度可压缩 的，所有数据压缩将偏移真的调制解调器链路吞吐量我们的测量。
执行下行链 路测试(从器到 PC) 起动 PC的 ttcpw 程序(在DOS窗口)，运行作为接受器。 参见README文件带有窗口TTCP软件为适当的语法。
C:\PROGRA~1\TTCPW>
ttcpw -r -s ttcp-r: buflen=8192, nbuf=2048,
align=16384/0, port=5001 tcp ttcp-r: socket
启动TTCP发送者(发射机)在AS5300。 留下多数设置在默认值，除了缓冲区数给传输。默认 缓冲区数是2048，TTCP测试将需要很长时间完成。通过减少 缓冲区数，我们能完成测试在一个合理的期限。
在如下所示的示例，我们设法确定一个调制解调器连 接的连接速率微软视窗PC和AS5300接入的之间。即使 这里包括的许多题目和解释是特定的对调制解调器连接，TTCP程序 可以使用在任何二个设备之间。
注 意： 设法得到调制解调器(端口)操作状态的快 照，如上所述，在您开始TTCP测试之前。
customer-dialin-sj>ttcp
transmit or receive [receive]:
transmit
!--- The AS5300 is the ttcp transmitter
Target IP address: 10.1.1.52
! -- Remote device (the Windows PC) IP address
perform tcp half close [n]: use tcp driver [n]: send buflen [8192]: send nbuf
[2048]: 50
!--- Number of buffers to transmit is now set to 50
(default is 2048 buffers)
bufalign [16384]: bufoffset [0]: port
[5001]: sinkmode [y]: buffering on writes [y]: show tcp information at end [n]:
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)
这造成Cisco IOS TTCP建立与TTCPW的TCP联系(在 Windows机器)。
当PC收到要求TTCP会 议时，TTCPW显示消息PC接受了一次TTCP会议从路由器IP地址：
ttcp-r: accept from 10.1.1.1
得到结果 当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 。在 网络服务器上安装此工具在接入服务器
【责编:admin】
--------------------next---------------------
