data link Story: Step 3: Use ttcp or nttcp to measure the end-to-end TCP performance

Step 3: Use ttcp or nttcp to measure
the end-to-end TCP performance

A network application may use either UDP (User Datagram Protocol) or TCP (Transmission Control Protocol) as its basic transport method. Which transport method you select depends on whether you are more concerned about timely transmission or reliability.

UDP is generally used by real-time applications where timely transmission is more important than reliability. Some applications can tolerate the loss of some information in transmission--many audio and video applications, for example. In simple terms, by using UDP, your application sends out packets as fast as the local host can handle, but you risk packet loss and swamping the network. A well-behaved application should implement some traffic shaping mechanism to achieve reasonable and optimal throughput. A common practice would be to acquire feedback from the receiver(s) and adjust the sending rate accordingly. More information about UDP is available at http://www.whatis.com/udp.htm.

TCP has built-in flow control mechanism and is reliable. TCP is the choice for most applications, as it ensures reliable transfer of all data. To achieve maximum TCP throughput, you need to set your TCP window size, which should be large enough to hold the TCP segments before an acknowledgement comes back. Theoretically, the optimal window size is:

bandwidth delay product = bandwidth * packet RTT

where bandwidth is the minimal bandwidth of a link along the path and packet RTT is measured by a ping. More details about TCP is available at http://www.whatis.com/tcp.htm.

For example, if the bottleneck along your path is a 100BaseT Ethernet, count the bandwidth to be 100 Mbps. From the first example, assume the average RTT is 61.5 ms, which makes the bandwidth delay product 769 Kbytes. In C socket programming, you can call the function setsockopt to set the window sizes to be the size you want. The default TCP window sizes on many systems are fewer than 32K bytes, which is usually too small for a fast WAN (so called "long fat pipes"). Note, however, that for local-area network applications, the default window sizes usually work just fine because the delay is much smaller than in WANs.

Use the ttcp tool to test the TCP throughput in different window sizes. You start the ttcp utility at one machine in server mode, which waits for TCP traffic. Then you start another ttcp at another machine in client mode, which sends a large chunk of data to the server. ttcp calculates the average throughput after the transmission is done. By setting different window sizes in multiple runs, you can determine the optimal window size between those particular machines. Because TCP performance may be asymmetric due to many factors, you should run ttcp in both directions to test the throughput.

The example below shows a ttcp test from an NCSA machine to one at the North Carolina Supercomputer Center (NCSC). Both centers are connected to the vBNS, and the correct routing is in place. ttcp at cyclops (NCSC) was started in server mode, and ttcp at bombadil (NCSA) was started as a client. The TCP window size used in this example was 64 Kbytes.

cyclops> ttcp -r -s -b 65535 -f m
ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001,
sockbufsize=65535 tcp
ttcp-r: socket
ttcp-r: rcvbuf
ttcp-r: accept from 141.142.6.19
ttcp-r: 8388608 bytes in 10.19 real seconds = 6.28 Mbit/sec +++
ttcp-r: 5728 I/O calls, msec/call = 1.82, calls/sec = 562.26
ttcp-r: 0.0user 0.3sys 0:10real 3% 776maxrss 0+0pf 5744+37csw
bombadil> ttcp -t -s -b 65535 -f m -n 1024 cyclops.ncsc.org
ttcp-t: buflen=8192, nbuf=1024, align=16384/0, port=5001,
sockbufsize=65535 tcp -> cyclops.ncsc.org
ttcp-t: socket
ttcp-t: sndbuf
ttcp-t: connect
ttcp-t: 8388608 bytes in 9.95 real seconds = 6.43 Mbit/sec +++
ttcp-t: 1024 I/O calls, msec/call = 9.95, calls/sec = 102.95
ttcp-t: 0.0user 0.1sys 0:09real 1% 0i+0d 0maxrss 0+2pf 0+0csw

ttcp is available in C source code at ftp://ftp.sgi.com/sgi/src/ttcp/. If you have trouble using it, contact NLANR distributed application support team at dast@nlanr.net or by calling tollfree 1-888-643-7666. A Java version of the ttcp tool is available at the dast.nlanr.net website.

nttcp is a similar tool to ttcp and may be easier to use because you can start it up as a daemon on a system if you have that privilege. nttcp is available at http://www.leo.org/~elmar/nttcp/

If you already have a C network application and wonder how it performs, Netlog and Viznet are the right tools for you. Netlog is a C library that logs your network calls. Viznet is a Java visualization tool to interpret the logs online in real time or offline by reading a log file. These tools were developed by the NLANR distributed application support team and are available on the dast.nlanr.net website.

Need Help With Your Network Application?

--NLANR/DAST staff