Testing throughput with TTCP and Cisco Devices

Even if you have been around networking for a while you may have never ran into the TTCP utility. This utility also comes by the name of PCATTCP. It’s a really small command line, data sending, and throughput testing tool. It sends as much data as possible to another remote instance of TTCP. Cisco devices with newer IOS software (11.2 and newer, so a lot of old stuff too by that standard…) and advanced feature sets such as service provider and advanced IP services include this tool, according to the old Cisco documentation I’ve read. This tool was present on our network’s 6500, 3750, and 3550 series switches as well as a 2821, 2620 and a 3700 series router. It is worth mentioning I confirmed these units were all running advanced IP versions of the IOS.
After reading that you probably logged right into an applicable Cisco and typed “?”. “ttcp” wasn’t on the list was it? This tool is actually hidden. Get yourself a “#” privileged mode prompt and type the entire thing: “ttcp”. Like I said, “?” and the tab key won’t help you find this command. This command is unsupported according to Cisco so results are not guaranteed. The command asks a series of questions. To listen for a connection the defaults are fine. I always select “y” when asked “show tcp information at end” by the menu.
Next, jump to your troubleshooting machine and fire up TTCP in a terminal window. The help menu looks something like this:

Usage: ttcp -t [-options] host [ < in ] pcattcp -r [-options > out]
Common options:
-l ## length of bufs read from or written to network (default 8192)
-u use UDP instead of TCP
-p ## port number to send to or listen at (default 5001)
-s toggle sinkmode (enabled by default)
sinkmode enabled:
-t: source (transmit) fabricated pattern
-r: sink (discard) all received data
sinkmode disabled:
-t: reads data to be transmitted from stdin
-r: writes received data to stdout
-A align the start of buffers to this modulus (default 16384)
-O start buffers at this offset from the modulus (default 0)
-v verbose: print more statistics
-d set SO_DEBUG socket option
-b ## set socket buffer size (if supported)
-f X format for rate: k,K = kilo{bit,byte}; m,M = mega; g,G = giga
-c -t: send continuously
-r: accept multiple connections sequentially
-R concurrent TCP/UDP multithreaded receiver
Options specific to -t:
-n ## number of source bufs written to network (default 2048)
-D don't buffer TCP writes (sets TCP_NODELAY socket option)
-w ## milliseconds of delay before each write (default 0)
Options specific to -r:
-B for -s, only output full blocks as specified by -l (for TAR)
-T "touch": access each byte as it's read

We want to hammer our listening Cisco with some data. Use the “-t” switch to transmit. An example would be like this:

C:\>ttcp -t
PCAUSA Test TCP Utility V2.01.01.08
TCP Transmit Test
Transmit : TCP ->
Buffer Size : 8192; Alignment: 16384/0
Connect : Connected to
Send Mode : Send Pattern; Number of Buffers: 2048
Statistics : TCP ->
16777216 bytes in 7.66 real seconds = 2138.90 KB/sec +++
numCalls: 2048; msec/call: 3.83; calls/sec: 267.36

You see the speed and other statistics of the transfer are displayed. Let’s jump back over to the Cisco to see what happened there:


transmit or receive [receive]:
receive packets asynchronously [n]:
perform tcp half close [n]:
receive buflen [32768]:
bufalign [16384]:
bufoffset [0]:
port [5001]:
sinkmode [y]:
rcvwndsize [32768]:
ack frequency [0]:
delayed ACK [y]:
show tcp information at end [n]: y
ttcp-r: buflen=32768, align=16384/0, port=5001
rcvwndsize=32768, delayedack=yes tcp
ttcp-r: accept from
ttcp-r: 16777216 bytes in 8657 ms (8.657 real seconds) (~1891 kB/s) +++
ttcp-r: 1047 I/O calls
ttcp-r: 0 sleeps (0 ms total) (0 ms average)
Connection state is CLOSEWAIT, I/O status: 1, unread input bytes: 1
Mininum incoming TTL 0, Outgoing TTL 255
Local host:, Local port: 5001
Foreign host:, Foreign port: 20859
Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes)
Event Timers (current time is 0x30D7B6A05):
Timer Starts Wakeups Next
Retrans 1 0 0x0
TimeWait 0 0 0x0
AckHold 1046 0 0x0
SendWnd 0 0 0x0
KeepAlive 0 0 0x0
GiveUp 0 0 0x0
PmtuAger 0 0 0x0
DeadWait 0 0 0x0
iss: 3423083471 snduna: 3423083472 sndnxt: 3423083472 sndwnd: 64240
irs: 4055091817 rcvnxt: 4071869035 rcvwnd: 31876 delrcvwnd: 892
SRTT: 37 ms, RTTO: 1837 ms, RTV: 1800 ms, KRTT: 0 ms
minRTT: 0 ms, maxRTT: 300 ms, ACK hold: 200 ms
Flags: passive open, retransmission timeout, gen tcbs
Datagrams (max data segment is 1460 bytes):
Rcvd: 12291 (out of order: 0), with data: 12288, total data bytes: 16777216
Sent: 10243 (retransmit: 0), with data: 0, total data bytes: 0


WOW… A lot of information… The main thing is the speed represented in Kb/s. Cisco also shows us some hardcore TCP statistics too, such as retransmits and AckHolds that are nice to know about when troubleshooting network bottlenecks or errors.

If you don’t have a Cisco device on the far side you can always fire up TTCP on a second PC, laptop, or whatever. “ttcp –r” is all that is needed to put your system into listening mode.

So what can you do with TTCP? The main reason I used this application was for testing throughput between two devices. Also, generating a ton of traffic under your control can be nice when testing QoS. Beating your router with this utility can help you double check your rate limiting configuration and traffic handling capabilities as well. If you are really in a hard place file transfer is even possible with this application between two PCs.

I hope you found this tutorial interesting and informative. If you are interested in learning more about this utility I have included a few links below.

Cisco: Using Test TCP (TTCP) to Test Throughput
Test TCP (TTCP) Benchmarking Tool and Simple Network Traffic Generator:

This entry was posted in Networking and tagged , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.