Measuring throughput with ttcp

Due date

Check the course schedule for the due date.

Introduction

Use the ttcp tool to measure effective bandwidth, or throughput, on an emulated network.  

Acknowledgments

This lab is based on experiments 11.1 and 11.2 from Hands-On Networking with Internet Technologies by Douglas Comer (2nd edition, 2005).

Goals

Logistics

You may work individually or in pairs. You have one week to complete this assignment.

Preparation

Do a Google search for "ttcp" and read whatever looks interesting. (Don't worry, there is not too much.) In particular, look out for the Wikipedia article and "The Story of the TTCP Program."

Assignment

Part A: Experimental setup

Create an Emulab experiment with a network configured as follows:
Start your experiment. Note that if you are having difficulty acquiring enough nodes, you can create a smaller network with only two nodes and one link; it is just that you will need to reconfigure the network several times in part C of the lab.

Part B: Loopback throughput

  1. Connect to node A using ssh.

  2. Read the manpage for the ttcp program.

  3. On your node, test ttcp in loopback, that is, connecting back to the same computer. Start one copy in receive mode and another in transmit mode.  I suggest you use the -s option so that ttcp will automatically source (that is, create) and sink (discard) its own data. You can use the -n option to tell ttcp how many buffers of data to send; this should be sufficiently large that the transfer takes tens of seconds.

    For example,

    > ttcp -r -s &
    [1] 2121
    > ttcp -t -s -n 100000 localhost

    You will have to wait while the data is transferred---be patient!  Note that ttcp transfers data using tcp by default.

  4. In your lab notebook, record the size of data sent (in bytes) and the time taken (in seconds). Record the throughput in Kbps or Mbps. (Note you will need to convert bytes to bits; Google or a spreadsheet can do this easily.)

  5. Repeat the loopback test using UDP (the -u option).  Record the size, time, and throughput. How does UDP throughput compare to TCP throughput? 

  6. Using TCP to obtain measurements, measure the throughput for buffer sizes ranging from 16KB to 208KB in increments of 32KB. Use the -b option to specify the socket buffer size. Record your measurements in a file or spreadsheet and plot the data. Paste your plot into your lab notebook. 

  7. The -T option causes the sending ttcp to "touch" each byte of data as it is read, to emulate processing on the receiver. Repeat the TCP experiment in exercise 5 with the -T option set for the receiver. How much is throughput affected?

Part C: TCP throughput on 10 and 100 Mbps networks

  1. Connect to node B using ssh.
  2. Measure TCP throughput on the 100 Mpbs LAN as follows.

    Run the ttcp receiver on node A, and the sender on node B.  For the sender, instead of a destination of localhost give the short name of the other machine (e.g., nodeA).

    Transfer at least 100000 buffers, or enough data that the transfer takes tens of seconds. Be patient! But, it is more important that the connection take long enough time to reach steady state, than that you transfer all 819200000 bytes of data. If you wait more than about 60 seconds and it has not yet stopped, it is OK to hit CTRL-C on the sender. The throughput data collected will still be good.

  3. Conduct a series of 5 such experiments, sending data from one node to the other. Record the throughput each time.

  4. Compute and record three values:

  5. Repeat your experiment with the 10 Mbps LAN by using nodes A and C. You can reduce the transfer size, as long as it still takes tens of seconds to complete the transfer. Compare the results.

  6. Repeat your experiment with the 10 Mbps, high latency link. Compare the results.

Part D: UDP throughput on 10 and 100 Mbps networks

Part E: Reading source

Part F: TCP throughput across "real" networks (extra credit)

If you have further time and interest, use ttcp to measure TCP throughput across one or more "real" networks. To do this, try the following steps.
  1. Identify two or more machines where you have login access and can install/run ttcp. (ttcp is installed by default on FreeBSD; there is a Darwin package to install it on Mac OS; you can also get it for Linux.)

  2. Locate, download, compile, and/or install ttcp on at least two machines.

  3. Record the hostname, IP address, and geographic location (if known) of each machine.

  4. Use the ping program to determine the RTT between each pair of machines. (You do not need to determine the bandwidth. Why would RTT be easier to measure than the "true" bandwidth of the network path?)

  5. Conduct the experiment in part B, exercises 3 and 4, for one or more pairs of machines. You may want to try doing the same pair twice, reversing the role of sender and receiver. What do you learn?

Assessment

To earn a B, complete parts A, B, and C of the assignment, along with the discussion questions.

To earn an A, also complete parts D and E.

For extra credit, also complete part F.

Advice

I hope the Emulab tutorial will be good preparation for this experiment. You may need to refer back to the tutorial to remind you how to do some things.

The ttcp manpage is very useful. There are also some online tutorials; if you find one useful, please cite it in your lab notebook and share it with others.

Feel free to ask for help (from me or your classmates) if you get stuck.

Lab Notebook

Include 

Discussion Questions

Answer the following questions to the best of your understanding.

  1. Why is throughput not infinite for the loopback configuration?
  2. Why does the use of a different transport protocol (UDP vs TCP) affect throughput?
  3. What is the socket buffer size in ttcp? Why does it affect throughput?
  4. How does link utilization compare for a 10 Mbps versus a 100 Mbps link? Form a hypothesis as to why this relationship exists.
  5. Why would latency affect throughput?
  6. How long did you spend on this lab?

Janet Davis (davisjan@cs.grinnell.edu)

Created January 29, 2009
Last revised February 19, 2009