Visualizing Connection Bandwidths and Delays in PlanetLab

Download: planetlab.zip (4.2Mb), decompress it, and go to the folder created.

To run on Windows, click on the icon for planetlab.bat.
To run on Linux, type "chmod +x planetlab.csh" followed by "./planetlab.csh"
To run on a GeoWall, use planetlab_geowall.bat or planetlab_geowall.csh.

Navigation: See the Cosmus site for instructions on how to use Partiview, the viewer being used here. It's quite simple, if you can handle a two-button mouse.

Matei Ripeanu had some data from his running of an overlay application on top of PlanetLab nodes. In his words:

Our data does not present PlanetLab itself but only one overlay application that runs on top of it. Overlays establish logical relationship between pairs of participating nodes (these are the links we present) and, for most overlays it is important to choose these logical links so that they map 'well' on the underlying network topology. Our 6-step 'animation' presents the evolution of the overlay right after bootstrap: it evolves from 'random' to having good topological properties (stress and stretch).

We have submitted a paper that describes in more detail the application (multi-source multicast), the success metrics, and the heuristics used to evolve the overlay.

The data is of the following form:

    128.8.126.69       147.83.30.168     71.736         1245.62
    128.143.137.249    128.143.137.250    0.729001     11697.97
    ...

The first line means that a transmission from the PlanetLab node with ip address 128.8.126.69 to the node at 147.83.30.168 took 71.736 milliseconds (this is called the link's delay), and that the bandwidth of the link was 1245.62 Kbps.

Matei supplied six files (1, 2, 3, 4, 5, 6) that "have the data for 6 graph snapshots (trees routed at 128.135.11.24 + some extra edges) at 4 minute intervals". He also supplied latitudes and longitudes in the file planetlab.dat. These were found with some automated tool that doesnt always work correctly, hence some nodes at latitude=longitude=0, which is somewhere of the coast of Gabon.

There are existing tools to see this kind of data, such as the PlanetLab Visualizer and Joseph Insley's GVis. However, they work on 2d maps, and we were curious if having things on a globe would make better use of the third dimension in displaying this information.

We used color to represent delay : green = low (i.e. a fast link), yellow = ok, orange = uh-oh, red = ouch.

We used height to represent bandwidth. By height we mean the distance from the highest point on the link to the center of the earth. The slowest links are at radius 2*EarthRadius from the center. Some of the highest-bandwidth links are very local, they show up as spikes, as in the snapshot above right.

Usually bandwidth is represented by the width of a link, not by its height. Height seems to be a lot easier to interpret, especially in cluttered graphs, as it uses the third dimension.

To produce this data, use the file planetlab.cf and then, for each ?.dat file (here 1.dat), say

perl earthgraph.pl 24.5 planetlab.dat 1 3 4 2 1.dat 1 2 3 4

This produces planetlab_1.speck, planetlab_1.label and planetlab_1_edges.speck. The first two are the same for all ?.dat files, the third is different, and what you want.


D.Surendran 08/04/04, Modified with some of Matei's explanations, and a correction of the timesteps (step 2 wasnt appearing before) on 08/16/04.