Marco,

O que acha de implantar aqui o esquema e enviar o post por email? acho que é uma funcionalidade muito util, alem de ajudar a divulgar o blog.

att
Rodrigo Colen

Serve para medir e informar o tamanho das Janelas TCP tanto do roteador quanto do micro PC usado na rede LAN.

segue o link :

http://www.cisco.com/en/US/tech/tk801/tk36/technologies_tech_note09186a0080094694.shtml

USING TEST TPC (TTCP) TO TEST THROUGHPUT

Contents

Introduction
Before You Begin
Conventions
Prerequisites
Components Used
Preparing for the TTCP Session
Performing the Downlink Test (from the Router to the Windows PC)
Obtaining the Results
Analyzing the Results
Performing the Uplink Test (from the Windows PC to the Router)
General Guidelines
Related Information

Introduction

You can use the Test TCP utility (TTCP) to measure TCP throughput through an IP path. To use it, start the receiver on one side of the path, then start the transmitter on the other side. The transmitting side sends a specified number of TCP packets to the receiving side. At the end of the test, the two sides display the number of bytes transmitted and the time elapsed for the packets to pass from one end to the other. You can then use these figures to calculate the actual throughput on the link. For general information on TTCP, refer to Network Performance Testing with TTCP /images/exit.gif .

The TTCP utility can be effective in determining the actual bit rate of a particular WAN or modem connection. However, you can also use this feature to test the connection speed between any two devices with IP connectivity between them.
Before You Begin
Conventions

For more information on document conventions, see the Cisco Technical Tips Conventions.
Prerequisites

Readers of this document should be knowledgeable of the following:

*

TTCP requires Cisco IOS® Software Version 11.2 or higher and Feature Sets IP Plus (is- images) or Service Provider (p- images).

Note: The ttcp command is a hidden, unsupported, privileged mode command. As such, its availability may vary from one Cisco IOS software release to another, such that it might not exist in some releases. Some platforms, for instance, require the Cisco IOS Enterprise feature set in order to perform this activity.
*

The TTCP software for the client side is available from http://renoir.csc.ncsu.edu/ttcp/; /images/exit.gif download ttcpw.zip /images/exit.gif for Windows clients.

Components Used

This document is not restricted to specific software and hardware versions.
Preparing for the TTCP Session

*

Ensure that there is IP connectivity between the two devices involved in the test.
*

Download and install the TTCP software for non-IOS clients, if necessary.

In the example shown below, we try to determine the connection speed of a modem connection between a Microsoft Windows PC and an AS5300 Access Server. Even though many of the topics and explanations that are included here are specific to modem connections, the TTCP utility can be used between any two devices.

Use the show modem operational-status command (for a modem link) to check the connection parameters. For other LAN or WAN scenarios, this step is not necessary.

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

This edited output shows that the client is connected in V.90 at a 45333 bps downlink rate and a 24000 BPS uplink rate. Data compression is disabled on the client modem. Since the TTCP test pattern is highly compressible, any data compression would skew our measure of true modem link throughput.
Performing the Downlink Test (from the Router to the Windows PC)

*

Start the ttcpw program on the PC (in a DOS window), running as a receiver. Refer to the Readme file provided with the windows TTCP software for the appropriate syntax.

C:\PROGRA~1\TTCPW>
ttcpw -r -s ttcp-r: buflen=8192, nbuf=2048,
align=16384/0, port=5001 tcp ttcp-r: socket

*

Launch the TTCP sender (transmitter) on the AS5300. Leave most settings at the default, except for the number of buffers to transmit. The default number of buffers is 2048, with which the TTCP test would take a long time to complete. By reducing the number of buffers, we are able to finish the test in a reasonable timeframe.

In the example shown below, we try to determine the connection speed of a modem connection between a Microsoft Windows PC and an AS5300 Access Server. Even though many of the topics and explanations that are included here are specific to modem connections, the TTCP utility can be used between any two devices.

Note: Try to get a snapshot of the modem (port) operational-status, as described above, just before you begin the TTCP test.

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)

This causes the Cisco IOS TTCP to make a TCP connection to the TTCPW (on the Windows machine).

When the PC receives the request for the TTCP session, TTCPW displays a message that the PC has accepted a TTCP session from the router’s IP address:

ttcp-r: accept from 10.1.1.1

Obtaining the Results

When the TTCP sender has finished sending all its data, both sides will print the throughput statistics and terminate. In this case, the IOS TTCP sender shows:

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)

The PC TTCPW receiver, on the other hand, shows:

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

At this point, you may want to take another snapshot of the modem or port operational-status. This information can be useful during analysis to check whether, for example, the modem connection experienced any retrains or speedshifts.
Analyzing the Results

Since it is most common to evaluate connect speeds in kbps (kilobits per second, or 1000 bits per second) rather that KBps (kilobytes per second, or 1024 bytes per second), we must use the information from TTCP to calculate the bit rate (in kbps). Use the number of bytes received and the transfer time to calculate the actual bit rate for the connection.

Calculate the bit rate by converting the number of bytes into bits and then divide this by the time for the transfer. In this example, the windows PC received 409600 bytes in 84.94 seconds. We can calculate the bit rate to be (409600 bytes * 8 bits per byte) divided by 84.94 seconds=38577 BPS or 38.577 kbps.

Note: The receiver-side results are slightly more accurate, since the transmitter might think it is finished after it performs the last write - that is, before the data has actually traversed the link.

Relative to the nominal link speed of 45333 BPS (determined from the show modem operational-status command), this is an 85 percent efficiency. Such efficiency is normal given the link access procedure for modems (LAPM), PPP, IP and TCP header overhead. If the results are significantly different from what you expect, analyze the operational-status, the modem log and, if necessary, the client-side modem statistics to see what may have happened to impact performance (such as EC retransmits, speedshifts, retrains and so on.)
Performing the Uplink Test (from the Windows PC to the Router)

Next, perform an uplink throughput test. This is identical to the downlink test, except that Cisco IOS TTCP acts as the receiver, and Windows TTCPW is the transmitter. First, set up the Router as the receiver, using the default parameters:

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

Activate the PC as the TTCP transmitter and specify the IP address of the router. Refer to the Readme file provided with the windows TTCP software for the appropriate syntax:

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

The IOS receiver reports the following results:

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)

This comes out as an uplink throughput of 141144 BPS - or almost a 6:1 compression ratio relative to the nominal uplink rate of 24 kbps. This is an interesting result considering hardware compression is disabled (which we determined from show modem operational-status). However, use the IOS command show compress to check whether any software compression is being used.
General Guidelines

Here are some general guidelines for using TTCP to measure IP path throughput:

*

For meaningful results, the hosts running TTCP should have plenty of CPU power relative to the link speed. This is true when the link is 45 kbps and the hosts are an idle AS5300 and a 700MHz PC. This is not true if the link is 100baseT and one of the hosts is a Cisco 2600 router
*

Cisco IOS treats data sourced by the router differently from data routed through the router. In our example above, although Microsoft Point-to-Point Compression (MPPC) compression was negotiated on the link under test, the data transmitted by the router did not use software compression, while the data transmitted by the PC did. This is why the uplink throughput was significantly greater than the downlink throughput. For performance testing of high bandwidth links, you should always test through the routers.
*

For IP paths with a large bandwidth * delay product, it is important to use a TCP window size sufficient to keep the pipe full. In the case of modem links, the default 4 KB window size is normally adequate. You can boost the IOS TCP window size with the command i p tcp window-size. Refer to the appropriate documentation for non-IOS systems.

Another easy way to test the throughput across a modem link is to use the open source tool Through-Putter /images/exit.gif . Install this tool on a web server behind the Access servers and have the Windows PC clients use a browser to call up the Java tool. It can then be used to quickly determine the data rate on a modem connection. This modem throughput applet is open source tool and is not supported by the Cisco Technical Assistance Center. Refer to the Readme file provided with the tool for further installation and operating instructions.

5.

Alguns destes comandos eu já conhecia, outros são sinistros mew O,O.

Achei show de bola, Marco/Rodrigo.

Abraços,
Anderson

E fica aqui mais alguns links de comandos nao documentados.

http://www.elemental.net/~lf/undoc/
http://www.madness.at/~mad/cisco_ios_udc.html
http://ccie-lounge.blogspot.com/2007/06/undocumented-cisco-ios-commands.html
http://www.heinzulm.com/hu03.html

Abs