Measuring throughput with ttcp

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

• Learn about and experiment with a tool for measuring effective bandwidth.
• Set up a real experiment in Emulab. Further consider the uses of network emulation.

Logistics

You may work individually or in pairs. If you work with a partner, please submit only one writeup.  (One partner's lab notebook can link to the other.) You have one week to complete this assignment.

Preparation & Resources

Assignment

Part A: Experimental setup

• There are four nodes running FreeBSD. Name these A, B, C, and D.
• Nodes A and B are connected by a 100 Mbps LAN with 0 latency. (A latency of less than 1 ms is typical for a local area network. With a latency of 0 ms on Emulab, you should get the true latency of the underlying physical network.)
• Nodes A and C are connected by a 10 Mbps LAN with 0 latency.
• Nodes A and D are connected by a 10 Mbps link with 100 ms of latency. (This is typical for a connection across the U.S.)

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

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 3 with the -T option set for the receiver. How is throughput affected?

Part C: TCP throughput on 10 and 100 Mbps networks

1. Connect to node B using ssh. (You should already have an ssh connection open to node A.)

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! However, it is more important that the connection take long enough time to reach steady state, than that you transfer all 819,200,000 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:

   • the mean throughput in bits per second (Mbps or Kbps);
   • the standard deviation; 
   • the link utilization, that is, the percentage of the underlying network that was occupied by data.

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: Reading source 

Obtain the C language source code for ttcp, read/skim it, and write a paragraph or two giving a high-level explanation of how it works. (Note: The code is not hugely long, but neither is it well-documented. Do your best, but don't obsess!)

Part E: More Experiments

Competing traffic

Create an experimental network topology in a "barbell" shape: Two "servers" should connect to a single router, two "clients" connect to a single router, and the two routers connect to each other.

Run two ttcp instances simultaneously across two client-server pairs.  How is TCP throughput affected by having two competing flows? What if the bottleneck is the "core" link vs. the "edge" links?

Include your experimental setup, procedure, and results in your lab notebook.

You may wish to extend your experiment to more than two client-server pairs. What do you think will happen?

Pathrate

Pathrate is a tool for measuring bottleneck bandwidth. Revise your experimental configuration from part A to use Linux as the node OS, install pathrate (if it is not already installed), and measure bottleneck bandwidths using pathrate. How do they compare to the effective bandwidths measured using ttcp? How does the method used for measuring bandwidth differ? When might one approach or the other be preferable?

References:

TCP throughput across a "real" network

1. Identify two or more machines where you have login access and can install (if necessary) and 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?

TCP throughput across the Internet using ProtoGeni

If you do not have login access to two computers in different locations, you may still observe throughput over the Internet using ProtoGeni, a system of hosts in various locations that are dedicated to experiments on the wide-area Internet.

References:

• Tutorial
  
• GUI manual
  

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 (one or more options).

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 

• your ns configuration files, 
• pictures of the network topologies, 
• the procedures followed (describe in English what you did) and results obtained for your experiments, and 
• your answers to the discussion questions below.

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? Where did you run into difficulty?
   

Janet Davis (davisjan@cs.grinnell.edu)