Version 3 (modified by, 9 years ago) (diff)


This tutorial is under development. We are actively working on updating it, if you need help please contact

Sample Experiment: UDT Evaluation


In this experiment, you will compare the performance of UDT (UDP-based Data Transfer) to TCP (transmission control protocol) in a simple network under varying conditions.

This experiment is based on work carried out at the University of Missouri - Kansas City, by Sunae Shin, Kaustubh Dhondge, and Baek-Young Choi. Their paper "Understanding the Performance of TCP and UDP-based Data Transfer Protocols using EMULAB" was presented at the First GENI Research and Educational Experiment Workshop (GREE2012), March 15-16, 2012, Los Angeles, CA. link to paper


Before beginning this experiment, you should be prepared with the following.


  • Download the attached rspec file and save it on your machine. (Make sure to save in raw format.)
  • Create a new slice and reserve the resources specified in the RSpec. If you use Flack, your sliver should look something like this:

No image "UDTExperimentSliver.png" attached to UDTExampleExperiment/VMOnly


You will use the following techniques during this experiment.

File Transfer Using UDT

Follow these steps to perform a file transfer using UDT.

  • Log into pc1 and pc2 in separate windows.
  • On pc1, start a UDT file transfer server, using this command:
    % pc1:~% /local/udt4/app/sendfile
    server is ready at port: 9000
  • On pc2, start a UDT file transfer client, using this command:
    pc2:~% /local/udt4/app/recvfile pc1 9000 /local/datafiles/sm.10M /dev/null

You should see output like the following in your pc1 window, showing the results of the file transfer. Note the transfer rate.

new connection:
speed = 7.14472Mbits/sec
  • There are three data files available for transfer tests: /local/datafiles/sm.10M is 10MB, /local/datafiles/med.100M is 100MB, and /local/datafiles/lg.1G is 1000MB. Leave your transfer server running on pc1, and try transferring each of these files in turn by typing the appropriate commands on pc2. Keep track of the transfer rates in each case.
  • You can leave your UDT server running or stop it with ctrl-C.

File Transfer Using FTP

Follow these steps to perform a file transfer using FTP.

  • For a TCP-based (FTP) transfer, there's already a FTP server running on pc1. Log into pc2, and start an ftp client:

(You type ftp pc1, the user name anonymous, and any password you want, although your e-mail address is traditional.)

pc2:~% ftp pc1
Connected to PC1-lan1.
220 (vsFTPd 2.3.2)
Name (pc1:mberman): anonymous
331 Please specify the password.
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
  • Still on pc2, request a file transfer. Note the reported file size, transfer time, and transfer rate.
ftp> get med.100M /dev/null
local: /dev/null remote: med.100M
200 PORT command successful. Consider using PASV.
150 Opening BINARY mode data connection for med.100M (104857600 bytes).
226 Transfer complete.
104857600 bytes received in 8.91 secs (11491.9 kB/s)
  • You can perform additional transfers with additional get commands. When you're done, exit the ftp client with the quit command.

Viewing and Adjusting link characteristics

In this experiment, you'll be changing the characteristics of the link and measuring how they affect UDT and TCP performance.

There are three link characteristics we'll manipulate in this experiment: bandwidth, delay, and packet loss rate.

It is possible to adjust the parameters of the two directions of your link separately, to emulate asymmetric links. In this experiment, however, we are looking at symmetric links, so we'll always change the settings on both directions together.

Here are the command sequences you'll need to change your link parameters. In each case, you'll need to provide the correct data plane interface (usually eth1), if they're different from the example.

  • To change bandwidth (100mbit means 100Mbits/s) do the following on both PC1 and PC2:
    sudo /sbin/tc qdisc add dev eth1 root handle 1:0 tbf limit 1000000 burst 1000000 rate 10mbit
  • To remove the rate limit do the following on both PC1 and PC2:
    sudo /sbin/tc qdisc del dev eth1 root
  • To change link delay (delays are measured in ms) do the following on both PC1 and PC2:
    sudo /sbin/tc qdisc add dev eth1 root handle 1:0 netem delay 10ms
  • To change packet loss rate (rate is a probability) do the following on both PC1 and PC2:
    sudo /sbin/tc qdisc add dev eth1 root handle 1:0 netem drop 0.1%
  • You can combine settings for bandwidth, delay, and loss by specifying more than one in a single command. We'll use this form in the procedure below.

Experiment Procedure

  • Using this initial setting, try a few UDT transfers, including the larger files. Now try FTP transfers. Record the transfer sizes and rates.
  • Now change the link parameters to reduce the available bandwidth to 10Mbps (on the data plane interface on both PC1 and PC2):
sudo /sbin/tc qdisc add dev eth1 root handle 1:0 tbf limit 1000000 burst 1000000 rate 10mbit
  • Repeat your file transfers with the new settings. As before, note the transfer sizes and rates, as well as the link settings.
  • Continue with additional trials, varying each of the three link parameters over a range sufficient to observe meaningful performance differences. Record your data.

What to hand in

  1. Your raw data and appropriate graphs illustrating changes in performance for the two transfer protocols with differing link parameters.
  2. Your analysis. Here are some questions to consider.
    1. Does one protocol outperform the other?
    2. Under what conditions are performance differences most clearly seen? Why?
    3. What shortcomings in the experiment design may affect your results? How might you improve the experiment design?
    4. What interesting characteristics of the transfer protocols are not measured in this experiment? How might you design an experiment to investigate these?

Attachments (2)

Download all attachments as: .zip