[chord] Analyze Chord in Planetlab?

[Hai Dao Le]

Thanks for your advice. Actually, I just start to learn the source code
so I couldn't fully understand you right now. I would like to briefly
introduce my project for you to know the possibility of success.

 

My project aims at improving the Chord topology-awareness by using
anycast. It is successfully evaluated by using p2psim. Now I want to
have some practical results in Planetlab but I am not sure how much
difficult it will be. Here are my questions:

1.    Firstly, I need to modify some parameters of Chord. I think with
the current number of nodes in Planetlab, successor list and predecessor
list of 16 seems too large. How can I reduce those numbers (about 2 or
3)? 

2.    Where can I find the source code of maintaining the finger table
and those above lists?

3.    How much different between the original Chord (described in the
paper "Chord: A Scalable Peer-to-peer ...") and the recent Chord that
deployed in Planetlab? 

4.    The stretch that I mentioned is the ratio of the total latency
that a query travels through the overlay network to reach an object and
the latency of the direct path to that object

 

Best regards,

 

Hai

-----Original Message-----
From: Emil Sit [mailto:sit at MIT.EDU] 
Sent: Friday, October 13, 2006 5:25 AM
To: Hai Dao Le
Cc: chord at amsterdam.lcs.mit.edu
Subject: Re: Analyze Chord in Planetlab?

 

On Thu, 12 October 2006 at 23:27 (+0900), Hai Dao Le wrote:

> Now I am going to do my experiment on Chord. Do you (or anyone) know
how

> can I analyze Chord? (e.g. calculate path length, stretch, ...).

 

I think if you send lsd a USR1 signal, it will dump a bunch

of stats to stderr that may include the average number of hops

(path length).  Unfortunately, it is not easy to extract

that from all the other junk that gets sent to stderr.

(Look for "Average # hops: [0-9.]+" perhaps.)

 

There isn't any code that calculates average stretch for you.

You'd have to define what you meant exactly (e.g., latencies

change over time) and add code that tries to figure it out.

You could at least time how long lookups take on average by

taking advantage of route_recchord's start_time variable

in route_recchord::handle_complete.

 

-- 

Emil Sit / MIT CSAIL PDOS / http://pdos.csail.mit.edu/chord/  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://amsterdam.lcs.mit.edu/pipermail/chord/attachments/20061023/31342afa/attachment.htm