Skip to content. | Skip to navigation

Personal tools


You are here: Home / Wiki / Kb100


Emulab FAQ: PlanetLab: Moving back and forth between PlanetLab and Emulab

Emulab FAQ: PlanetLab: Moving back and forth between PlanetLab and Emulab

PlanetLab gives you widely variable network and node conditions. This is its strength - you're running on the real Internet. Sometimes, though, you'd rather develop, debug, or test under more controllable, repeatable conditions. Emulab can help you out with this. This document will help you go back and forth between experimentation on Emulab and PlanetLab.

We have other, more comprehensive introductions to Emulab, but this one is specifically targeted towards users familar with PlanetLab. Once you're done with this one, you may want to [doc.php3 check them out]. We also have a frontend to PlanetLab, which can help you create and manage slices. It has a separate document.

Getting an Emulab account is similar to getting a PlanetLab account - a PI from your institution starts a project, and then students, staff, etc. join it. The full process is documented here.

The first difference to notice is the difference in experiment specification betwen PlanetLab and Emulab. An Experiment in Emulab is roughly equivalent to a Slice in PlanetLab. Whereas on PlanetLab, you pick from a list of nodes to instantiate your slice on, in Emulab, you supply a network topology with information such as delay, bandwidth, and packet loss between the nodes. This is done with a variant of the popular ns simulator language. Emulab then creates an emulation of that network for you, by picking nodes and links whithin our facility, and applying taffic shaping to get the network characteristics you aksed for. This allows you control over your environment, and gives you very good repeatability.

Another difference is the way in which resources are allocated. In PlanetLab, the slivers in your slice are on shared machines. In Emulab, the nodes in your experiment are not shared with anyone else - Emulab isolates experiments from each other so that your results will not be affected by any others that may be running at the same time. Thus, you are expected to only hold onto nodes while you are using them - if you go home for the night (and aren't running some experiment overnight), you are expected to "swap out" your experiment so that others can use the nodes. Emulab will, in fact, enforce this policy and swap you out automatically if it detects that your experiment has gone idle.

Since you have exclusive access to the nodes in your experiment, you have complete root access. You're free to replace any disk contents you want, etc. Emulab will clean off the disk for the next user once you're done with it. All users in a project ("institution" in PlanetLab) have their own accounts on the nodes, instead of the one-account-per slice model of PlanetLab. You have an NFS home directory and project directory accessible on all of your nodes. You can run several versions of Linux, FreeBSD, and Windows on the nodes in your experiment. If your goal is to build an application that can run easily on both Emulab and PlanetLab, we suggest that you use our PLAB-DEVBOX disk image.

PlanetLab gives you acess to real Internet path characteristics. Emulab, on the other hand, creates the characteristics you'd like to use in an Emulator. Basically, you tell us what packet loss, bandwidth, and delay you'd like to see, and we create it artifically within our facility using traffic shaping. One way of creating Internet-like conditions in Emulab is to model the InterNet as a fully-connected LAN. Unlike a reguar LAN, however, you'll be able to set traffic shaping characteristics on every node, so that they communicate as if they were in different parts of the world rather than in the same machine room. You can use the `tb-set-node-lan-*` commands to accomplish this.

Another important difference is the Control Net, which exists on Emulab, but not on PlanetLab. The control net separates traffic that is part of your experiment and traffic that is for control. For example, when you ssh into an Emulab node, you do so over the control network. Similarly, your NFS home directory is mounted using the control network. The traffic shaping is done on the Experimental Network, and not on the control network.

This means that you need to be aware of multi-homing issues. You'll need to make sure that your application binds itself to the experimental net, not the control net. To help you do this, we've created a program called isonet which does this binding for you, without having to modify your application.