140 likes | 280 Views
RAMBO Implementation. Peter M Musial piotr@cse.uconn.edu September 13, 2002. Software Language. Java 2 Platform Std. Ed. v1.4.0 Communication library Sending objects Thread library Each IOA action is a thread Synchronization tools Atomic access to state variables
E N D
RAMBO Implementation Peter M Musial piotr@cse.uconn.edu September 13, 2002
Software Language • Java 2 Platform Std. Ed. v1.4.0 • Communication library • Sending objects • Thread library • Each IOA action is a thread • Synchronization tools • Atomic access to state variables • Implementation size: 5500 lines of code • Room for improvement
Scheduling • Need a fair scheduler • Round-robin schedule • by use of synchronization • Round-robin time per service • 50 to 200 ms or more depending on work load • IOA actions • Once allowed to execute • Read the state variables • Check preconditions • If preconditions met, do work, update state, exit • else, exit • Make a call to synchronization mechanism
Communication • Point-to-point messages • TCP protocol • All messages sent as objects • Input IOA actions • Have assigned socket • Sockets are not shared between actions • Composition actions • Based on “Implementation and Evaluation of an Eventually Serializable Data Service” by Oleg M. Cheiner
Consensus • Centralized consensus • Designated machine as consensus server • Simulation • Static delay of 8d between receiving suggested value and returning decision • Turn around of Cons service dictates performance of Reader-Writer • Delay d not the same for Reader-Writer and Cons • Recon does not have a set delay, only that of round-robin schedule • Plan to implement Paxos in the future
Testing & Data Collection • Environment • Driver forcing actions • Controlled by the user • Automation options • Repeated reconfigurations • Repeated read/write operations • Driver preserves well-formedness of trace
Reconfigurations • Centralized Cons • Well-formedness • Propose next config only if previous succeeded or failed • Set of valid configurations supplied • 13 machines participating • Majority quorum • All possible configurations such that read/write quorums are not the same
Read/Write Test • Well-formedness • For each read wait for read-ack • For each write wait for write-ack • At the local node no overlapping read/write operations • Data collected • Average • Max • Min
Garbage-Collection • Cmap state variable of Reader-Writer • Stored in a Vector • R.I.P. configurations are physically deleted • Indirect indexing to the Vector • Recon • Remove unused information • Example: reported {c(1),c(2),c(3),c(4),c(9)} • Remove c(1), c(2), c(3) • Let c(k) be a learned cmap then if k < 4, then do not report else report. • Other variables are cleaned up using similar logic
Testing Environment • Hydra Beowulf Cluster • Linux Red Hat 7.1 • 100 Base switch interconnect • Ping time << 10ms • Heterogeneous set of machines • Fastest: dual PII 900MHz with 256 MB mem • Slowest: Intel 90 MHz with 32 MB mem
Hydra Beowulf Cluster 192.168.27.2 nemesis.hydra.net nemesis PII 200MHz 64MB 192.168.27.3 zeus.hydra.net zeus PII 200MHz 64MB 192.168.27.4 athena.hydra.net athena Intel 166MHz 16MB 192.168.27.5 morpheus.hydra.net morpheus PII 200MHz 64MB 192.168.27.6 apollo.hydra.net apollo PII 200MHz 64MB 192.168.27.7 aphrodite.hydra.net aphrodite PII 200MHz 64MB 192.168.27.8 poseidon.hydra.net poseidon PII 200MHz 64MB 192.168.27.9 ares.hydra.net ares (server) 2xPII 900MHz 256MB 192.168.27.12 io.hydra.net io Intel 90MHz 49MB 192.168.27.13 hours.hydra.net hours Intel 166MHz 32MB 192.168.27.14 iris.hydra.net iris Intel 90MHz 49MB 192.168.27.16 muses.hydra.net muses Intel 90MHz 64MB 192.168.27.17 odysseus.hydra.net odysseus Intel 90MHz 49MB
Preliminary Results • Configuration details • 13 machines in the members set • 7 machines in each read/write quorums • All configurations have different read/write quorums