International Buillion and Metals corporation (IBM) was happy with the program you wrote for project 2, but they suspect that it was not as efficient as it could be. They re-wrote the program to use a single, centralized Broker, so that the broker could look at all pending orders and allocate resources to them "optimally". They tried four different algorithms, but cannot decide which is best, so they have hired you and your partner as consultants to analyze them.
They want a written report from you by March 25.
You can find the simulator in ~cs537-2/public/html/source/p3. Copy all the files to a new directory, compile them by typing
jikes *.java
and run the program by typing something like
java Project3 1 3 100
Take a look at the source files. See also the online documentation. You will note many similarities with Project2, but there are also some important differences. Instead of one Broker for each metal, there is now one centralized Broker that accepts get orders from all consumers and controls how they are processed. The Broker is now a class rather than an interface (so there is no more BrokerImplementation) and it now has its own thread. Whenever a new order is placed by a Consumer or metals are delivered by the Refiner, notify() is called to wake up the Broker. It allocates resources according to one of four algorithms according to the first command-line argument (1 in the example above). You will probably need to make small changes to the code for your experiments.
The details of the program are controlled by several parameters initialized in the constructors for Consumer and Refiner. You will need to experiment with changes to these parameters. You may also need to add code to gather other statistics on the performance of the three algorithms.
The behavior of a Consumer is controlled by the parameters meanSleepTime and maxPurchase. The meanSleepTime is the average time (in milliseconds) that the consumer delays between making purchases. The actual time is an exponentially distributed random number with mean meanSleepTime (in the jargon of statistics, this is called a Poisson arrival process). The array maxPurchase controls the amount of each metal purchased by the consumer. The actual amount of metal i requested is a random number uniformly destributed over the interval [0,maxPurchase[i]], so that the mean purchase is maxPurchase[i]/2. As you can see, not all consumers need to have the same behavior.
The behavior of the Refiner is controlled by the parameters meanSleepTime and maxDelivery. Like consumers, the Refiner repeatedly sleeps an exponentially distributed random time and then delivers a random amount of each metal to the broker. The code as distributed attempts to balance the rates of production and consumption of resources. That is, the Refiner tries to generate metals at roughly the same rate (on the average) as consumers consume them. (How well does it do?) After the number of iterations specified by the third command-line parameter, the Refiner calls Broker.shutDown(), which causes the consumers all to print statistics and halt.
The behavior specified by the -r flag on project 2 is now the default. Each thread has its own random number generator, which is initialized by a constant seed. Thus multiple runs of the program with the same settings and arguments should give similar results. You my wish to try changing these initializations to see how much the results you see are caused by random fluctuations and how much they are caused by the algorithm and the parameters.
First, look at the methods Broker.algorithm1(), Broker.algorithm2(), Broker.algorithm3(), and Broker.algorithm4(). Unfortunately, the IBM programmers failed to include any comments. What is each algorithm trying to accomplish? Are they analogous to any of the scheduling algorithms discussed in class? What sort of behavior would you expect from each of these algorithms? Should one be "better" than all the others? Perhaps one or another is best depending on the goals (response time, total amount consumed, fairness, etc.).
Next, design and some experiments to test your hypotheses. Carefully analyze the results of your experiments. After an initial analysis, you may find that you need to run additional experiments to gather more information.
You should approach this portion of the assignment as you would approach a laboratory assignment in a physics course. Use the scientific method. You should form some hypotheses before you start experimenting and use the experiments to confirm or reject these hypotheses based on observed results. Give careful thought to the correct choice of parameters for the programs. Try a few trial runs with various parameters, print out the results, and go home and think about the results. These preliminary results should help you decide on better parameters for a second round of trials. Remember: It's not just the quantity but also the quality of data that determines the quality of your results. It's perfectly ok if your initial hypotheses do not agree with the experimental results. Remember that the purpose of the experiments is to determine the truth, not to confirm your prejudices.
If the program is not printing out all the statistics you would like to see, feel free to modify it to produce better output. You may find additional statistics-reporting code can help explain some of the behavior you observe.
You are to prepare a report describing the results of your experiments. Again, approach this report as you would approach a physics laboratory experiment report. You should carefully describe what experiments you did and what the results showed you about the different allocation policies. Did the experimental results confirm or refute your initial hypostheses? How should your hypotheses be modified to confirm to the results? We want to see a correlation between the experiments you run and the conclusions you draw. You must supply quantitative data to support your conclusions. The report should be not more than three typewritten pages, excluding tables, graphs, etc.
Put a copy of your code (.java files only) in the appropriate subdirectory of ~cs537-2/handin. If you have changed partners, let us know as soon as possible. Include all .java files needed to build the program (even the parts we wrote and you didn't change). Do not include .class files. In each .java file, include a comment of the form
// Partner: login1 login2where login1 and login2 are the login names of the partners.
The report itself will be hard copy only (do not try to hand in MS
Word
documents or whatever). Bring your report to class on Thursday (Mar
25).