Introduction

The Test TCP utility is a simple but highly flexible sockets application that can be used to perform simple Internet performance tests. It is widely available because the TTCP application can be ported to any host that supports BSD sockets. See the topic TTCP Background for more information.

TTCP Features

TTCP is a flexible testbed that includes simple tests that exercise the most common Internet protocols:

  • TCP Client (Transmitter)

  • TCP Server (Receiver)

  • UDP Client (Transmitter)

  • UDP Server (Receiver)

TTCP tests can be configured using a command-line interface. Here are some representative configurable test parameters:

  • Length of buffers read from or written to the network.

  • Number of buffers to send.

  • Buffer alignment and offset.

  • Socket options, including: SO_SNDBUF, SO_RCVBUF, TCP_NODELAY.

  • Port number.

PCATTCP is PCAUSA's port of TTCP to Windows. In addition to the basic TTCP features described above, the latest PCATTCP version includes some PCAUSA Extensions to TTCP:

  • Option to send TCP/UDP data continuously for long-term tests.

  • Optional operation of concurrent multi-threaded TCP and UDP servers to allow tests to be rerun without having to restart after each test.

Data Transferred By TTCP

There are two basic "modes" used by TTCP to transfer test data:

Sinkmode

The simplest and most popular TTCP mode of operation is called "sinkmode". In this mode of operation the TTCP transmitter sends a fabricated data pattern and the TTCP receiver simply sinks (discards) any data that it receives.

This is the default TTCP mode of operation.

Standard Streams

Alternatively, TTCP can use what is called "standard streams" or "standard I/O". Standard streams are facilities that are provided in most common operating systems - including DOS, all versions of Windows as well as Unix. However, many Windows users may not be familiar with them. Standard streams are associated with the "Command Prompt" window - a powerful facility avoided by many Windows users.

If you are familiar with the Windows "Command Prompt", then TTCP:

      • Can read data to be transmitted from stdin (the keyboard, by default).

      • Write received data to stdout (the console screen, by default).

Going a little further, by using "Command Prompt" features called "redirection" it is actually possible to transfer a file from one machine to another using TTCP. This isn't a very practical file transfer mechanism. However, it can be useful in some tests.

A description of the use of the "Command Prompt" is beyond the scope of this document. If you understand it, then it should be useful to you.


Background

Test TCP (TTCP) - The Original BSD Tool

Test TCP (TTCP) is a command-line sockets-based benchmarking tool for measuring TCP and UDP performance between two systems. It was originally developed in 1984 by Mike Muuss and Terry Slattery for the BSD operating system. The original TTCP and sources are in the public domain, and copies are available from many anonymous FTP sites.

WSTTCP - A Port Of TTCP To Windows Sockets

Sungjin Chun <sjchun@janus.sst.co.kr> of Samsung Electronics Ltd. ported TTCP from BSD to Windows Sockets as WSTTCP in 1996. WSTTCP is available in executable form on WinSite.

WSTTCP Executables from WinSite

The only problem with WSTTCP is that sources are apparently not available.

PCATTCP - PCAUSA's Port Of TTCP To Windows Sockets

The PCATTCP program is simply PCAUSA's port of TTCP to Windows Sockets.

PCATTCP V1.0 was made in April, 1999 and is also in the public domain - at least from the PCAUSA site.

The original port of TTCP to Windows Sockets was fairly straightforward. Only a small number of changes were required to adapt TTCP for operation under Windows.

The code for the current V2.01.01.03 version has been substantially reworked to suit the author's style and purpose (as a sockets programming learning program and a TCP/IP exploration tool).

Modifications, including the use of threads and Microsoft-specific Winsock extensions, as well as enhancements to TTCP functionality have been made by PCAUSA.

However, the current version is backwards compatible to at least to PCATTCP V1.0.

The PCATTCP distribution includes both the PCATTCP executable program and source code.


What's New In This Release

  • New Documentation

  • Enhancements:

    • An option to send continuously, instead of stopping after sending a specified number of buffers.

    • A receiver that would automatically restart after each test (the receiver was in another room...).

  • Better Error Messages

  • Code extensively re-written.


Contacting PCAUSA

PCAUSA does not offer any formal support for this application. However, help is provided on a time-available basis on the PCAUSA Discussion List, described below.

PCAUSA Websites

PCAUSA licenses a variety of specialized code for network programmers working on the Windows platforms.

PCAUSA Newsletter

If you have licensed a PCAUSA product it is important that you subscribe to the PCAUSA Newsletter/Mailing List. PCAUSA uses this opt-in email mailing list to send periodic (infrequent, not SPAM) information about PCAUSA product updates, new PCAUSA products and information of general interest to network software developers.

You can view the archive of the PCAUSA Newsletter at:

<http://groups.yahoo.com/group/pcausa/>

You can subscribe to the PCAUSA Newsletter on the group web page or by sending email to:

<pcausa-subscribe@yahoogroups.com>

PCAUSA Discussion List

This PCAUSA opt-in email mailing list provides a forum for users to discuss PCAUSA products as well as the more general topic of Windows low-level network programming.

You can view the archive of the PCAUSA Discussion List at:

<http://groups.yahoo.com/group/discussion-pcausa/>

You can subscribe to the PCAUSA Discussion List on the group web page by sending email to:

<discussion-pcausa-subscribe@yahoogroups.com>

General Office Information

Telephone Numbers:

Voice: (770) 432-4580

FAX: (770) 436-7246

Mailing Address:

Printing Communications Assoc., Inc. (PCAUSA)

4201 Brunswick Court

Smyrna, GA 30080

USA


Command-Line Arguments

PCATTCP is a Win32 console application. It is intended to be run from the Windows Command Prompt. Its operation is controlled by typing the program name followed by a series of option strings.

Running PCATTCP

You start the PCATTCP application by first opening a Command Prompt Window. The change to the directory that contains the PCATTPC application (PCATTCP.exe).

As an example, to start the TTCP TCP Receive Test start PCATTCP with the "-r" option.

C:\ PCADev\TTCP pcattcp -r

The TCP receiver will start and then wait until a remote TTCP client makes a connection attempt.

Exiting PCATTCP

You can exit the PCATTCP application by entering "Ctrl-C". To enter "Ctrl-C" hold down the Ctrl key and then perss the 'c' key. This calls the PCATTCP Ctrl-C handler which causes the program to exit.

Usage Message

As an aid in remembering the option strings you can just run PCATTCP with no options and it will display the following "usage message":

C:\ PCADev\TTCP pcattcp -h

Here is an example of the output you would see:

PCAUSA Test TCP Utility V2.01.01.02

Usage: pcattcp -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)

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

Some Examples of Running PCATTCP

It is not necessary for you to understand all of the PCATTCP options. Here are links to topics that illustrate basic usage:

  • TCP Transmit Test

  • TCP Receive Test

  • UDP Transmit Test

  • UDP Receive Test

  • Concurrent TCP/UDP Receiver Server


TCP Transmit Test

To start the TTCP TCP Transmit Test start PCATTCP with the "-t" option followed by the dotted IP address or hostname of the remote TTCP client.

C:\ PCADev\TTCP pcattcp -t 192.168.1.101

Here is an example of the output you would see:

PCAUSA Test TCP Utility V2.01.01.03

TCP Transmit Test

  Transmit    : TCP -> 192.168.1.101:5001

  Buffer Size : 8192; Alignment: 16384/0

  TCP_NODELAY : DISABLED (0)

  Connect     : Connected to 192.168.1.101:5001

  Send Mode   : Send Pattern; Number of Buffers: 2048

  Statistics  : TCP -> 192.168.1.101:5001

16777216 bytes in 1.75 real seconds = 9362.29 KB/sec +++

numCalls: 2048; msec/call: 0.88; calls/sec: 1170.29

These messages are generated as the test starts up:

PCAUSA Test TCP Utility V2.01.01.03

TCP Transmit Test

  Transmit    : TCP -> 192.168.1.101:5001

  Buffer Size : 8192; Alignment: 16384/0

  TCP_NODELAY : DISABLED (0)

These messages indicate that a connection has been established with the remote host:

  Connect     : Connected to 192.168.1.101:5001

  Send Mode   : Send Pattern; Number of Buffers: 2048

When the test exits it displays the test results:

  Statistics  : TCP -> 192.168.1.101:5001

16777216 bytes in 1.75 real seconds = 9362.29 KB/sec +++

numCalls: 2048; msec/call: 0.88; calls/sec: 1170.29


TCP Receive Test

To start the TTCP TCP Receive Test start PCATTCP with the "-r" option.

C:\ PCADev\TTCP pcattcp -r

The TCP receiver will start and then wait until a remote TTCP client makes a connection attempt. Here is an example of the output you would see:

PCAUSA Test TCP Utility V2.01.01.03

TCP Receive Test

  Local Host  : twoeye400

**************

  Listening...: On port 5001

  Accept      : TCP <- 192.168.1.105:1548

  Buffer Size : 8192; Alignment: 16384/0

  Receive Mode: Sinking (discarding) Data

  Statistics  : TCP <- 192.168.1.105:1548

16777216 bytes in 33.77 real seconds = 485.22 KB/sec +++

numCalls: 2051; msec/call: 16.86; calls/sec: 60.74

These messages are generated as the test starts up:

PCAUSA Test TCP Utility V2.01.01.03

TCP Receive Test

  Local Host  : twoeye400

**************

  Listening...: On port 5001

These messages indicate that a TCP connection has been accepted from a remote host:

  Accept      : TCP <- 192.168.1.105:1548

  Buffer Size : 8192; Alignment: 16384/0

  Receive Mode: Sinking (discarding) Data

When the test exits it displays the test results:

  Statistics  : TCP <- 192.168.1.105:1548

16777216 bytes in 33.77 real seconds = 485.22 KB/sec +++

numCalls: 2051; msec/call: 16.86; calls/sec: 60.74


UDP Transmit Test Output

UDP Transmit Test

To start the TTCP UDP Transmit Test start PCATTCP with the "-u" option followed by the "-t" option followed finally by the dotted IP address or hostname of the remote TTCP client.

C:\ PCADev\TTCP pcattcp -u -t 192.168.1.101

Here is an example of the output you would see:

PCAUSA Test TCP Utility V2.01.01.03

UDP Transmit Test

  Transmit    : UDP -> 192.168.1.101:5001

  Buffer Size : 8192; Alignment: 16384/0

  Send Mode   : Send Pattern; Number of Buffers: 2048

  Statistics  : UDP -> 192.168.1.101:5001

16777216 bytes in 1.92 real seconds = 8524.45 KB/sec +++

numCalls: 2050; msec/call: 0.96; calls/sec: 1066.60

These messages are generated as the test starts up:

PCAUSA Test TCP Utility V2.01.01.03

UDP Transmit Test

  Transmit    : UDP -> 192.168.1.101:5001

  Buffer Size : 8192; Alignment: 16384/0

  Send Mode   : Send Pattern; Number of Buffers: 2048

When the test exits it displays the test results:

  Statistics  : UDP -> 192.168.1.101:5001

16777216 bytes in 1.92 real seconds = 8524.45 KB/sec +++

numCalls: 2050; msec/call: 0.96; calls/sec: 1066.60


UDP Transmit Test

To start the TTCP UDP Transmit Test start PCATTCP with the "-u" option followed by the "-t" option followed finally by the dotted IP address or hostname of the remote TTCP client.

C:\ PCADev\TTCP pcattcp -u -t 192.168.1.101

Here is an example of the output you would see:

PCAUSA Test TCP Utility V2.01.01.03

UDP Transmit Test

  Transmit    : UDP -> 192.168.1.101:5001

  Buffer Size : 8192; Alignment: 16384/0

  Send Mode   : Send Pattern; Number of Buffers: 2048

  Statistics  : UDP -> 192.168.1.101:5001

16777216 bytes in 1.92 real seconds = 8524.45 KB/sec +++

numCalls: 2050; msec/call: 0.96; calls/sec: 1066.60

These messages are generated as the test starts up:

PCAUSA Test TCP Utility V2.01.01.03

UDP Transmit Test

  Transmit    : UDP -> 192.168.1.101:5001

  Buffer Size : 8192; Alignment: 16384/0

  Send Mode   : Send Pattern; Number of Buffers: 2048

When the test exits it displays the test results:

  Statistics  : UDP -> 192.168.1.101:5001

16777216 bytes in 1.92 real seconds = 8524.45 KB/sec +++

numCalls: 2050; msec/call: 0.96; calls/sec: 1066.60


Concurrent Multi-Threaded TCP/UDP Receivers

To start the TTCP Multi-Threaded TCP/UDP Receivers start PCATTCP with the "-R" (note capitalization).

C:\ PCADev\TTCP pcattcp -R

In this mode of operation PCATTCP operates in a multi-threaded node. In this mode PCATTCP starts both the TCP test receiver and the UDP test receiver concurrently. In addition, the receivers operate in the "continuous mode; this means that at the end of each test they restart the receivers for a new test without exiting.

In addition, in this mode the TCP receiver is capable of accepting a small number of concurrent clients.

Here is an example of the output you would see:

PCAUSA Test TCP Utility V2.01.01.03

  Threading   : Multithreaded

UDP Receive Test

  Protocol   : UDP

  Port       : 5001

TCP Receive Test

  Buffer Size : 8192; Alignment: 16384/0

  Local Host  : twoeye400

**************

  Listening...: On port 5001

  Accept      : TCP <- 192.168.1.105:1547

**************

  Listening...: On port 5001

  Buffer Size : 8192; Alignment: 16384/0

  Receive Mode: Sinking (discarding) Data

  recvfrom    : UDP <- 192.168.1.102:2295

  Statistics  : UDP <- 192.168.1.102:2295

16777216 bytes in 3.06 real seconds = 5350.75 KB/sec +++

numCalls: 2049; msec/call: 1.53; calls/sec: 669.17

  Accept      : TCP <- 192.168.1.101:3266

**************

  Listening...: On port 5001

  Buffer Size : 8192; Alignment: 16384/0

  Receive Mode: Sinking (discarding) Data

  Statistics  : TCP <- 192.168.1.105:1547

16777216 bytes in 37.91 real seconds = 432.23 KB/sec +++

numCalls: 2065; msec/call: 18.80; calls/sec: 54.48

  Statistics  : TCP <- 192.168.1.101:3266

367689728 bytes in 45.14 real seconds = 7954.63 KB/sec +++

numCalls: 72775; msec/call: 0.64; calls/sec: 1612.21

Ctrl+C Event

TTCP shutting down...

These messages are generated as the test starts up:

PCAUSA Test TCP Utility V2.01.01.03

  Threading   : Multithreaded

UDP Receive Test

  Protocol   : UDP

  Port       : 5001

TCP Receive Test

  Buffer Size : 8192; Alignment: 16384/0

  Local Host  : twoeye400

**************

  Listening...: On port 5001

Notice that both the UDP Receive Test and the TCP Receive Test have been started.

The output messages generated from this point on are similar to those described for the individual receive tests.


File Transfer And Standard I/O

Here are some brief comments concerning File Transfer and Standard I/O with PCATTCP.

Note the standard I/O mode of operation is specified by including the "-s" option as a PCATTCP option.

These comments are based on the behavior of the Windows NT Command Prompt syntax.

Send A File Using TTCP

This sends the file junk.txt to the remote host 192.168.1.105 using TCP:

C:\ PCADev\TTCP pcattcp -s -t 192.168.1.105 < junk.txt

Save Received TTCP Data To A File

This saves data received from the remote host in the file receivedjunk.txt:

C:\ PCADev\TTCP pcattcp -s -r > receivedjunk.txt

Send Console Keystrokes (stdin) Using TTCP

This sends the console keystrokes to the remote host 192.168.1.105 using TCP:

C:\ PCADev\TTCP pcattcp -s -t 192.168.1.105 <

Display Received TTCP Data On Console (stdout)

This displays data received from the remote host in on the console screen:

C:\ PCADev\TTCP pcattcp -s -r > receivedjunk.txt

Save Error Messages (stderr) To A File

This redirects error messages (e.g., statistics, etc.) to the file stats.txt:

C:\ PCADev\TTCP pcattcp -s -r 2> stats.txt


Programmer's Guide

Source Directory Layout

The following table depicts the directory layout used for the PCATTCP V2.01.01.03 source code:

PCADev – Root for all PCAUSA Products

TTCP – Text TCP (TTCP) Root Directory

Doc – Documentation

Bin – Reference Executables

UnixTTCP – Original BSD Unix TTCP source

WSTTCP – Sungjin Chun's WSTTCP executable

PCAV1 – Sources for PCATTCP V1.00.00.02

PCAV2 – Sources for PCATTCP V2.01.01.04

PCATTCP V1.00.00.02

This was the original PCAUSA port of TTCP to Winsock. This was fairly straightforward. Sources for PCATTCP V1 are in the directory \PCADev\TTCP\PCAV1.

PCATTCP V2.01.01.03

Why bother? There's actually not much wrong in the original TTCP and PCATTCP V1.00.00.02.

Of course, the motivation is self serving. The author's next project was to review and enhance the PCAUSA kernel mode Transport Data Interface (TDI) samples. These samples include a kernel-mode version of TTCP that could use some cleaning up. Before embarking on the kernel mode work, the author decided to revisit the user mode Winsock version of TTCP.

We wanted to add two simple enhancements:

    1. An option to send continuously, instead of stopping after sending a specified number of buffers.

    2. A receiver that would automatically restart after each test (the receiver was in another room...).

The original Unix programming style was a little difficult for the author to read:

    3. Revise programming style to suit PCAUSA. This was a massive change, and PCATTCP V2 is now a Win32-specific application (although functionally it is compatible with other TTCP implementations).

Although PCATTCP V2 uses blocking sockets, it was modified to include multi-threaded receiver operation.

    4. Multi-threaded operation.

There were some minor "bugs" and "loose ends" in PCATTCP V1:

    5. Systematic release of acquired resources.

    6. Show correct Winsock error codes on socket operation failure.

Finally, downloads of the PCATTCP application are fairly popular. So, a decision was made to share at least some of this work with the public.

Sources for PCATTCP V2 are in the directory \PCADev\TTCP\PCAV2.

We hope it is useful to you.

Notes: 1.) At this time these goals are on hold and are not provided in this release. We'll get around to them someday...


Frequently Asked Questions

Why do I get a tremendous discrepancy in sender/receiver UDP statistics on Gigabit Ethernet?

Congratulations!

The TTCP UDP test is an excellent tool for highlighting the fact that UDP is an unreliable protocol.

Here are some actual UDP test results with sender and receiver operating on full-duplex Gigabit Ethernet:

First the sender's statistics:

PCAUSA Test TCP Utility V2.01.01.03

UDP Transmit Test

  Transmit    : UDP -> 192.168.1.104:5001

  Buffer Size : 8192; Alignment: 16384/0

  Send Mode   : Send Pattern; Number of Buffers: 2048

  Statistics  : UDP -> 192.168.1.104:5001

16777216 bytes in 0.82 real seconds = 19931.87 KB/sec +++

numCalls: 2050; msec/call: 0.41; calls/sec: 2493.92

The test shows that the UDP transmitter made 2050 sendto() calls to send 16777216 bytes in 0.82 seconds.

Tremendous performance!!!

Or is it...

Now the receiver's statistics:

PCAUSA Test TCP Utility V2.01.01.03

UDP Receive Test

  Protocol   : UDP

  Port       : 5001

  Buffer Size : 8192; Alignment: 16384/0

  recvfrom    : UDP <- 192.168.1.101:3720

  Statistics  : UDP <- 192.168.1.101:3720

221184 bytes in 0.83 real seconds = 260.55 KB/sec +++

numCalls: 28; msec/call: 30.32; calls/sec: 33.78

The receiver made only 28 recvfrom() calls and fetched only 221184 bytes during the test.

The UDP receiver fetched only 1.3 percent of the data.

98.7 percent of the TTCP UDP data was lost!!!

The reason for this is that the UDP test is very simple. It takes no steps whatsoever to pace the output. It simply makes continuous calls to sendto() to transfer the data.

This test was actually useful when it was originally written. When it is run on slower networks (e.g. 10-BaseT Ethernet) on slower workstations the unreliability of UDP is not nearly so great.

PCAUSA considered trying to make a better UDP test. However, that would probably be reinventing TCP wouldn't it? In addition, the revised "better" test would not be a faithful implementation of the baseline TTCP test.

Why do the UDP tests sometimes not finish properly?

This is also related to the inherent simplicity of the TTCP UDP test. In particular, the method used to signal the start and end of a test is unreliable.

The TTCP UDP test uses datagram size to signal the beginning and end of a test.

The test is written so that all test data datagrams are greater then a minimum size called the GUARD_BUFFER_LENGTH. This is defined as four byte datagram. TTCP includes a check to insure that the buffer length that you specify with the "-l" option is never below this minimum.

This means that datagrams with length less then GUARD_BUFFER_LENGTH can be used by TTCP to identify the start and end of a UDP test. Here is the simple method that was implemented:

  • Start of UDP test identified by sending one short (length < GUARD_BUFFER_LENGTH) UDP datagram.

  • UDP test datagrams are sent (all have length >= GUARD_BUFFER_LENGTH).

  • End of UDP test identified by sending four (4) short UDP datagrams.

It should be clear that if any one of the five(5) guard datagrams is missed the test will not finish properly.