Page History

The most current list of landmarks can be found here.

There are two significant type of maintenance issues when we talk about TULIP. The problems we need to address are location change of landmarks and their uptime. These are: 

1. Whether the landmark is working.
2. obtaining accurate landmark locations and detecting location changes of landmarks

The problem with the landmarks being available working or not is discussed below in the Landmarks Laundering section below.

in landmarks laundering which is child to TULIP analysis page. The other significant problem is the location update of landmarks. We are getting obtaining and maintaining accurate location information for the landmarks. Initially we obtained the location of Planet Lab landmarks using the geoiptool, PingER landmark locations are provided by the site hosts and are manually added to Node Detail databaseusing  geoiptool or geotool, however, we have improved the methods as described below.  We intend to run a nightly cron trscron job to check if there is any host which has changed its position according to geoiptool. The maintainPL.pl script is currently deployed at

 /afs/slac/package/pinger/tulip/maintainPL.pl

If the value of Lat,Lon in MySQL is different from that obtained using geoiptool then that entry is written to the log file at

 /afs/slac/package/pinger/tulip/maintainPL-log.txt

We have also discovered problems with geoiptool in some of the hosts. One of the challenging problems were For example one challenging problem was two hosts(planetlab1.pop-mg.rnp.br,planetlab2.pop-rs.rnp.br) in Brazil . We did a ping between the host and got a response of 25~30 ms. Geoip tool Geoiptool showed that the hosts are at the same location which is about the center of brazil. We then inquired further and found the case interesting as the traceroute to both of them was going through different routes i.e. traversing different routers to reach the destination. After confirming the actual latititde and longitude from thier websites we updated the database manually. To cater for the problems like these the hash named errltln(Error in lat/long in geoiptool) contains the host which are not updated in the database with this script. The sample code is given below

#Error in lat/long in geoiptool
 my %errltln = (
 'planet01.hhi.fraunhofer.de' => '1',
 'planet02.hhi.fraunhofer.de' => '1',
 'planet-lab1.ufabc.edu.br' => '1',
 'cs-planetlab3.cs.surrey.sfu.ca' => '1',
 'planetlab1.pop-mg.rnp.br' => '1',
 'planetlab2.pop-rs.rnp.br' => '1',
 'csplanet02.cs-ncl.net' => '1'
 );

...

Laundering Landmarks

Finding the Latitude and Longitude of a Landmark Manually

TULIP Creating the Landmark XML files

Using Google Fusion Tables to record landmarks

We analyzed the possibility of using Google Fusion Tables/API to store landmarks from the TULIP database. Initial results indicate that keeping a Google Fusion Table in sync with a live url or having it to update itself as a change happens, in the database is not currently possible. These tables are really good, in case of static data, but as of this moment, the tulip database, gets updated daily. Atleast twice to enable or disable nodes, and atleast once to update planet lab nodes.

As of this moment, we have concluded, that we should skip this methodology and wait, for improvements, and newer versions of the API.

The sample table can be seen here: tulip_landmarks Node Manually