120 likes | 132 Views
Presentation. Advanced Operating System Maekawa vs. Ricart-Agrawala By Rizal M Nor. Introduction. My project implements two DMX algorithms, Ricart-Agrawala and Maekawa. The Maekawa algorithm is expected to be faster than Ricart-Agrawala algorithm
E N D
Presentation Advanced Operating System Maekawa vs. Ricart-Agrawala By Rizal M Nor
Introduction • My project implements two DMX algorithms, Ricart-Agrawala and Maekawa. • The Maekawa algorithm is expected to be faster than Ricart-Agrawala algorithm • Maekawa reduces the number of processes that must be contacted • Objective: • Implement the algorithms described above. • To study the performance of the algorithm. • To understand behavior of the algorithm.
Algorithms Short Review • Ricart-Agrawala: • A modification to Lamport’s DMX Algorithm (Request, Reply, Release) • Delay replies of request, therefore only (Request, Reply) messages • Reduces message complexity to: • Maekawa: • In Maekawa algorithm, each process is in a member of a set of neighbors (quorum). • Quorum: • The set of Si can be found by solving finite projective planes of N points • Symmetric when, N=K*(K-1)+1 (where k is a power of a prime) • A process enters critical section if it succeeds in acquiring locks from its entire quorum. (Request, Locked Release) • This reduces the message complexity of Maekawa algorithm to: • However, recall that Maekawa’s algorithm has 6 types of messages (Request, Locked Release, Failed, Inquire, Relinquish) • Hence in very high load, performance could go as large as:
Experiment Description • Ricart-Agrawala: • vary the size of the system, number of nodes(N) from 5 to 50 nodes in increments of 5. • for each system Size N, vary the size of contending nodes L for 1(node), 25%, 50%, 75% and 100% load. • For Maekawa, • vary the size of the system, number of nodes(N) according to: • symmetric pairwise nonnull intersecting set quorum sizes • Using preloaded value from a text file. • The sizes chosen is 7, 13, 21, 31, 57, 73, 91, 133 , 183, 307 , 381, 553, 871, 993 • These values are chosen because creating non-symmetric sets were difficult • for each system Size N, vary the size of contending nodes L for 1(node), 25% , 50%, 75% and 100% load.
Experiment Setup • Run the Simulator program with parameters: $ java –Dalgo=ricart –Dnodes=5 –Dload=5 Simulator > results.txt • Extracting Results • Using grep and wc program to capture tags in output • The command below calculates the amount of messages send by processor 0 to reach critical section $ grep “Processor * sends *” | wc –l 13 • Save output into excel • Calculate average number of messages sent by each processor requesting critical section. • Plot results in excel.
Results (Ricart-Agrawala) • Fixed N, Varying Load from the table below: • the size of message complexity does not change for ricart-agrawala. • In fact, it is exactly the same. • as expected since even though there might be more contending nodes, the amount of messages sent and receive by each node requesting critical section remains the same. • Varying N, Fixed Load from the table below: • The Message complexity changed linearly • Can be seen in graph above. • It can be seen the change is exactly 2*(N-1) without any variance. • As expected because each node requires to send to exactly N number of nodes twice for Request and Reply. • Hence. The linear growth.
Results (Maekawa) • Fixed N, Varying Load from the graph: • the size of message per CS required seems to increase as the load increases for any number of fixed N • As expected, the growth starts from for light load • However • Results are not as expected. Growth is not linear with respect to load. • In fact, the growth does not reach • Looking at the generated output file, it can be seen that at higher load (50%), most nodes requesting nodes will fail and can’t enter CS. • Extra FAILEDs messages needs to be sent. Number of Nodes
Results (Maekawa Continue) • Varying N, Fixed Load from the graph: • The Message complexity changed in the order of square root of N. • Regardless of the load size, there is a trend of growth for N. • The growth is close to a square root of N. • This behavior is because as N increases it will require more messages to be sent to the quorum. The quorum size is roughly square root of N. • However, as the load increases(50% below) • there is a constant change in the graph. • This is particularly because an increase in load will cause some constant amount of failed messages in the system. • Thus increasing the number of messages needed for CS. • At high loads(50% above), most of the nodes are requesting CS and hence most probably will be Locked or by itself or others.
Future Research • Study Maekawa’s algorithm, when the quorum size is not entirely symmetric. • generate a symmetric quorum from an optimized value of N greater that the desired size N. • Addition of nodes and how it affects the network • Making Ricart-Agrawala capable to work in an unreliable network. Where nodes gets removed out of the network. Reply responses are lose.
Code Design • Design • Simulator • The simulator is responsible to handle creation of nodes, selecting nodes by random to be run, and assigning channels to the nodes • Processor Class • An interface class to be implemented by any algorithm. • Class Maekawa and Ricart_Agrawala implements this class. • This design allows abstractioni from the Simulator main class to run the processes.
Code Difficulty • Design • Simulator • PRNG used for random no. is not purely random. Each instance of a class is seeded with the millisecond system time * 100 * process ID, however, I feel it is still lack the randomness I need. • Difficulty • Quorum Data Set • Not explained in the paper. Found out to be non-trivial. • Used data downloaded from a mathematical website. • Found out that the order of K=41 would take a long time to generate. There is none to be found right now. • Queues • Maekawa Priority Queue • Requires a priority queue, hence a special comparator is needed to be overriden by the default comparator to handle priority by seq. no and process id • Ricart-Agrawala Message Queue • The queue is non-fifo. • During send, insert the element in random order of the queue. This is to simulate messages arriving not in order sent.
Object Oriented Design Simulator <Uses> Processor <Implements> <Implements> <Uses> Member Set Ricart_Agra Maekawa LockQueue Comparator