You can use the Test TCP utility (TTCP) to measure TCP throughput
through an IP path. In order 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.

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.

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.

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.

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.

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.

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.

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.)

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:

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.

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 . 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.