Tarry vs Awerbuchs Shawn Biesan

Background Tarry’s Transversal Algorithm – Initiator forwards token to one of neighbors, each neighbor forwards token to all other nodes and when done returns token – Complexity: 2 * [number of edges] – Constructs spanning tree Awerbuchs – Node notifies neighbors that it is visited by sending so tokens are never sent over frond edges – Time complexity: 4 * [number of nodes] – 2 – Constructs spanning tree Time Complexity - Number of causally related messages

Experiment 2 experiments comparing time complexities – Varying number of processes 5-50, varied by 5 node increments – Varying density of partially connected graph Probability that there is an edge between two nodes varies from 30%-100%(fully connected) by increments of 10%, denoted as p Graph must be connected, if it isn’t the graph is regenerated until the created graph is connected Number of nodes is fixed at 10 – Each data point is the result of averaging 5 trials

Expected Results Tarrys time complexity will be better for sparse graphs – Its time complexity depends on number of edges(2E) whereas Awebuchs depends on the number of nodes (4N -2) As p increases Awerbuchs will improve until it has a better time complexity than Tarrys – Greatest difference between them for fully connected graphs

Result

Interpretation Awerbuchs is indeed better than Tarrys as nodes scale in a completely connected graph – The number of edges grows much faster than nodes ( #edges= (N(N-1))/2 ) Tarrys algorithm is indeed better for sparse graphs up until about p=0.4 – Expected value of number edges when p=0.4 is 18 so it matches up with theoretical

Code Most difficult/interesting part of the code was related to how the simulation engine was made – Each new algorithm must implement a specific interface in order to be used – Made adding new algorithms less painful

Conclusions And Future Work In general Tarry’s algorithm should be used for sparse graphs with small number of nodes, otherwise use Awerbuchs – Easier to implement – Sends less messages – No overhead of and messages Future Work – Explore different topologies – Explore Message Complexity deeper

Questions? Thank you