The FrugalDemo Package

Demonstrates the Frugal package.

This is a trimmed-down and parallelized version of a Java research tool. This tool originally tested various resource allocation strategies on a cluster of six simulated machines. Running the demo, you can see both the Frugal package at work and a demonstration of its decision-making algorithms.

FrugalDemo Parameters

FrugalDemo, at present, tests five different resource allocation strategies. These are:

PVM Straight round-robin allocation of jobs.

Differential PVM The Frugal strategy, without knowledge of the job's memory requirements.

Enhanced PVM The Frugal strategy, with knowledge of the job's memory requirements.

Mosix The strategy employed by a version of the Mosix operating system, which can move jobs as they run from one machine to another.

Enhanced Mosix The Frugal strategy, given Mosix's ability to move jobs from one machine to another.

If a job using the Frugal package runs in a series of steps, each step can ask for a new Frugal Resource. This gives some of the benefit of the last two strategies. Effectively, the job moves itself during execution to a less loaded machine.

The Frugal Demo simulates a cluster of 6 machines. Three are identical. Two are older machines, with half the power and memory. One is older yet, with 1/3 the power and 24/64th the memory of the strongest machines. This matches the cluster in the lab when the first experiments with Frugal's internal strategies were performed.

10,000 seconds are simulated, during which jobs arrive at a fast clip. Most of the jobs are reasonably small, although on occasion a batch of large parallel jobs arrives simultaneously. After 10,000 seconds, no further jobs come in. The scenario continues until the last job leaves the system, which can be almost immediate or a very long (simulated) time. Expect a scenario's execution to take a few real-time minutes -- sometimes less, sometimes more. Only 50 random scenarios are executed, so there is some variability in the results -- the Frugal framework's "edge" over other strategies increases with the average load.

FrugalDemo Options

You can run the FrugalDemo package in several ways.

With an option of the form "-v #", with # between 1 and 5, it graphically displays the performance of # strategies. Otherwise, you will see only text updates and output.

With an option of the form "-r #", with # between 1 and 5, it tests scenarios on # Frugal Resources simultaneously. Otherwise, it runs as a serial application that does not use RMI, Jini, or the Frugal package.

With an option of the form "-rt", the Demo package applies real-time constraints to some jobs. Otherwise, it assumes that no job is time-critical.

FrugalDemo Output

With the "-v" option on, FrugalDemo graphically displays one to five of the five resource allocation strategies tested. You can see jobs arrive on the system, see the strategies assign them to various machines, increasing their memory and CPU load, see the Mosix and Enhanced Mosix strategies reassign jobs when appropriate, and watch them leave the system when complete.

FrugalDemo also prints out a "snapshot" every 5 seconds. It gives you the current simulated time. It lists the number of jobs on all machines in each strategy. Even though jobs arrive at the same time in all strategies, different strategies finish jobs at a different rate. The more efficient a strategy is, the fewer jobs it will have on its system on average.

FrugalDemo also notes its start time in milliseconds and tells you when it deletes an old results file or starts a new execution. Early output might look like:

Old Results Deleted.
Time 950402593796
Running a Demo Worker.
Snapshot, Local Resource, t = 1700 seconds:
(PVM Method) 32 jobs on 6 machines.
(Differential PVM Method) 33 jobs on 6 machines.
(Enhanced PVM Method) 35 jobs on 6 machines.
(Mosix Method) 32 jobs on 6 machines.
(Enhanced Mosix Method) 33 jobs on 6 machines.
Snapshot, Local Resource, t = 4720 seconds:
(PVM Method) 67 jobs on 6 machines.
(Differential PVM Method) 74 jobs on 6 machines.
(Enhanced PVM Method) 65 jobs on 6 machines.
(Mosix Method) 61 jobs on 6 machines.
(Enhanced Mosix Method) 60 jobs on 6 machines.

FrugalDemo writes the results of each execution into a file, "results.txt". This looks something like:

Time: 950403975290
Execution 1
PVM Method
Current execution 19.21527777777778 | 5.612576064908722
Overall, PVM Method achieves 9.689406318082789 | 2.8678824978267166 (for 0/416/280 jobs)
Differential PVM Method
Current execution 2.3819444444444446 | 0.6957403651115619
Overall, Differential PVM Method achieves 3.0635893246187362 | 0.9209015502752824 (for 0/416/280 jobs)
Enhanced PVM Method
Current execution 3.423611111111111 | 1.0
Overall, Enhanced PVM Method achieves 3.3372821350762525 | 1.0 (for 0/416/280 jobs)
Mosix Method
Current execution 2.611111111111111 | 0.7626774847870182
Overall, Mosix Method achieves 2.7576252723311545 | 0.827142494929006 (for 0/416/280 jobs)
Enhanced Mosix Method
Current execution 3.0902777777777777 | 0.9026369168356998
Overall, Enhanced Mosix Method achieves 2.7359749455337687 | 0.8187361151357093 (for 0/416/280 jobs)

Let's analyze one of these reports to see what it's saying:

Mosix Method
Current execution 2.611111111111111 | 0.7626774847870182
Overall, Mosix Method achieves 2.7576252723311545 | 0.827142494929006 (for 0/416/280 jobs)

Our primary criterion is slowdown. Suppose that a job requires at least 10 seconds to complete in the best possible case. Because of system load, it takes 26.1 seconds instead. It has suffered a slowdown of 2.61. In this execution, the average slowdown over all jobs is 2.61111111111111111. This is 76.27% of the slowdown for Enhanced PVM, our baseline. That's the "Current Execution" line.

Averaged over all executions so far -- 2, in this case -- Mosix jobs experience a slowdown of 2.7576. This is about 82.71% of the slowdown for Enhanced PVM. That's the "Overall" line.

Interpret (for X/Y/Z jobs) as follows:
X, the first number, is the number of jobs rejected in order to satisfy real-time constraints. (0)
Y, the second number, is the total number of jobs seen so far. (416)
Z, the third number, is the number of jobs in this particular execution. (280)

First Run

To get an idea of how the FrugalDemo works, start it as follows:

        [start] java -cp
                /files/jini1_1/lib/jini-core.jar:
                /files/jini1_1/lib/jini-ext.jar:
                /files/jini1_1/lib/sun-util.jar:
		/files/jini1_1/lib/reggie.jar:
		/files/Frugal/FrugalDemo.jar
	-Djava.security.policy=/files/Frugal/yourpolicy
	edu.jhu.cnds.FrugalDemo.Demo
	-v 2 [&]

        Use [start] on Windows machines and [&] on UNIX machines.

Invoked this way, the FrugalDemo package does not use parallelization or Jini. It will test 5 different resource allocation methods on a cluster of six machines, each method given an identical random streams of jobs. It opens a graphical display window for 2 methods, PVM and Enhanced Mosix, showing jobs as they arrive and move around the system. This should give a feel for the way the research tool works.

Second Run

To invoke the FrugalDemo package on Jini, start up the Jini services, Frugal Resources, and a Frugal Manager. Then invoke the FrugalDemo as follows:

        java -cp
                /files/jini1_1/lib/jini-core.jar:
                /files/jini1_1/lib/jini-ext.jar:
                /files/jini1_1/lib/sun-util.jar:
		/files/jini1_1/lib/reggie.jar:
		/files/Frugal/FrugalDemo.jar
	-Djava.rmi.server.codebase=http://yourname.com/Frugal/FrugalDemo.jar
	-Djava.security.manager=java.rmi.RMISecurityManager
	-Djava.security.policy=/files/Frugal/yourpolicy
	edu.jhu.cnds.FrugalDemo.Demo
	-r 3

This starts up the FrugalDemo package, telling it to use 3 Frugal Resources and to display no graphical windows. You will see 3 updates every 5 seconds, one from each resource. At first, they will be synchronized. As scenario executions complete and new scenarios start asynchronously, the updates will drift out of lockstep.

Real Time Option

Invoking the research tool with the "-rt" option turns on real-time constraints for some processes. In order to satisfy real-time constraints, the system must have the ability to reject jobs. The less efficient methods will have to reject more jobs, reducing total system load. Thus, the average slowdown becomes a poor measure of system performance; instead, the number of jobs rejected becomes the important criterion.

Author: R. Sean Borgstrom
Version: 2.0