Version 28 (modified by Ben Newton, 9 years ago) (diff)


Calibrating for Tmix

This page describes how to run calibration experiments with Tmix on GENI nodes. This tutorial assumes that you are already familiar with basic experimentation with GENI, and that you have access to a machine from which you can execute ssh commands and login to external machines. If you wish to reserve resources using omni, some version of Linux or Unix running on a PC or virtual machine is required. The tutorial also assumes basic familiarity with Linux or Unix, and the ability to use a terminal text editor such as emacs, vim or nano.

At run-time Tmix "replays" the exchanges encoded in a set of connection vectors (or c-vecs). The connection vectors are extracted from traffic captured on a real network link. Since all of the traffic crossing a busy link cannot generally be replayed using a single pair of nodes, it is customary to split the connection vectors into N pairs of tcvec files. If all of the traffic observed on a busy link cannot be simulated with just two nodes, what percentage of the traffic can we replay? How many pairs of nodes do we need to use to simulate all the traffic? It is exactly these questions that calibration seeks to answer. Below we will walk through the process of determining how much traffic can be simulated by a single pair of nodes.

A Reserve Resources in Omni or GENI Portal

Determine whether you wish to use Omni or GENI Portal to reserve GENI resources for this Tutorial. We recommend you use GENI Portal, unless you are experienced with, or wish to gain experience with Omni. Click one of the links below that matches your choice. The image and setup are the same as in the Tmix Tutorial.

Reserve Resources using GENI Portal

Reserve Resources using Omni

B Login to nodes

Open two new SSH terminals, one to each node. On linux you will may use the following command log into each node reserved in the previous step.

ssh -i ~/.ssh/id_geni_ssh_rsa <username>@<hostname> -p <port>

As expected, <username> should be replaced with your GENI username, and <hostname> and <port> are replaced with the hostname and port of the reserved GENI resource noted in the previous step.

C Run Tmix Script and view data files

  1. The image loaded on the nodes has the tmix tools already installed and in your path. Each time the system boots, a kernel module is automatically inserted to assist in simulating the packet delays. Issue the following command on the SSH terminal of the "left" node to run a Tmix setup script
    sudo /local/
  1. Repeat the above command in the SSH terminal of the "right" node.
  1. Now, list the contents of your home directory on either node.

You should see a tmix.conf file, which contains the configuration for a tmix experiment. Open the file with an editor such as vim, emacs, or nano, and browse its contents. These are various settings that control a tmix experiment. At the end of the file notice the Crecv_Trace and Cinit_Trace lines. These are the only lines you will need to change as we run our calibration experiments.

  1. List the contents of the tmix data directory by typing the following on either node:
    ls /opt/tmix-1.2/data

A set of connection vectors is described by with a pair of tcvec files (labeled cinit.tcvec and crecv.tcvec). These two files correspond to connections that are initiated on either side of the link on which the traffic data was originally captured. Since all of the traffic crossing a busy link cannot generally be replayed using a single pair of nodes, it is customary to split the connection vectors into N pairs of tcvec files. Most of the files displayed in the listing are named 1ofN.crecv.tcvec. This is a single pair of connection vector files obtained by evenly splitting the original set of connection vectors into N parts. For example, running tmix with the pair of files, 1of10.crecv.tcvec and 1of10.cinit.tcvec, will replay about 1/10th the traffic originally recorded on the link. Below we will perform a set of experiments in which we iterate to find the point at which our pair of nodes can no longer work fast enough to simulate all the network traffic.

C Run Tmix Script and view data files

  1. Make a new directory for this experiment, change to it, and copy tmix.conf there by typing:
    mkdir 1of10
    cd 1of10
    cp ../tmix.conf .
  1. Edit the tmix.conf file using a terminal text editor such that your Crecv and Cinit lines are the following.
    Cinit_Trace = /opt/tmix-1.2/data/1of10.cinit.tcvec
    Crecv_Trace = /opt/tmix-1.2/data/1of10.crecv.tcvec

on the "left" node, and

Cinit_Trace = /opt/tmix-1.2/data/1of10.crecv.tcvec
Crecv_Trace = /opt/tmix-1.2/data/1of10.cinit.tcvec

on the "right" node. Note that the filenames are swapped on the "right" node. All you should need to change is what is after "data/" and before ".cinit" or ".crecv". You are now ready to run the tmix experiment.

  1. Tmix relies upon a pre-determined start time to synchronize tmix on the two nodes. On both nodes run the following command to determine the time and date:

Note that the time may be in a different time zone. Decide on a start time about a minute or two in the future, relative to the time displayed by the date command. It should be far enough in the future for you to issue the following command on both nodes and allow tmix to initialize.

  1. Finally, execute the following command on both nodes:
    tmix -s HH:MM:SS tmix.conf

where HH:MM:SS is the chosen start time in hours minutes and seconds.

  1. Tmix on both hosts will load the data files and then wait until the designated start time.

You will see "Running for ???? seconds" once tmix is ready to go. When the start time arrives, Tmix will start running for 12 minutes (a 10 minute experiment plus 2 minutes of buffer). You will not see any indication on the terminal that it has started running.

  1. One way to verify that tmix is running is to open another SSH terminal to either node and type:

This shows a listing of the most active processes. You should see tmix at the top of the list once it starts. Top can also give you an indication of what percentage of the CPU tmix is using ( in the %CPU column). If you see numbers near 80% or 90% you are near the capacity of the number of connections that this pair of nodes can simulate. To exit top type 'q'.

  1. Once the experiment is complete, a list of statistics will be output to the console. Also, a set of log files with extentions .ert, .trt, .unc, .rt, and .ts will be created in the directory. While tmix runs it is customary to experience a few errors, where connections fail to open or close. It is also customary to see several errors at the end of the experiment indicating that some connections failed to close. If, however, you see a steady stream of errors, something is wrong or you are trying to simulate too much traffic. Type "Ctrl-c" on both terminals, and verify your tmix.conf file, and ensure you followed the above directions.
  1. To determine the number of bytes transferred during your experiment type the following on the "right" SSH terminal:
    bytesTxfrd tmixTutorial.rt

Plotting this number in relation to the number of connection vectors for several experiments using different portions of traffic will allow us to determine at what point we can no longer reliably emulate traffic with a single pair of nodes. Running this command on the "left" node will give us the number of bytes in the opposite direction. This is not what we want to plot, however, because the bytes transferred in the opposite direction were less for the monitored link, and therefore are not the "weakest link", and will not be impacted as much when resources are saturated.

  1. To return to your home directory type:
    cd ..

D Iterate

Calibration Graph Repeat steps 1 through 9 of section C for various input files (i.e. 1of02.cinit.tcvec), and plot the resulting bytes transferred. You should reach a point where the linear growth stops. You can use the following table to record your results.

cvec file number of connections bytes transferred Notes

E Delete Resources

Once your experiment is complete and you have collected your results, you should return the reserved resources. To do so, follow the step below which matches your choice to use GENI Portal or Omni.

E.1 Using GENI Portal

  1. Click on slices in the upper right-hand corner.
  1. Find your slice in the list, and click on the corresponding Delete Resources button.
  1. Click "Delete Resources" again to confirm that you want to delete all reserved resources.

E.2 Using Omni

In the terminal execute the following command: -a pg-utah deletesliver <sliceName>

where <sliceName> is once again replaced with your chosen unique slice name.

Attachments (1)

Download all attachments as: .zip