使用测试TCP (TTCP)测试吞吐量

发布时间：2006-10-12 02:16:09　来源：友佳学院网友评论 0 条

当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 。在网络服务器上安装此工具在接入服务器之后并且让Windows PC客户端使用浏览器召集Java工具。在调制解调器连接可能然后用于它迅速确定数据速率。是开放源工具和Cisco技术支持中心不支持此调制解调器吞吐量附属程序。参见README文件带有进一步安装和操作说明书的工具。

3/3 首页上一页 1 23