CS 537-2: Spring 2000
Programming Assignment 3

Frequently Asked Questions (FAQ)

Q1:

Is there any more information available on how the simulator works?

A:

Yes, check out the page that we've added.

Q2:

What class files can we change? Do you have any hints on what we will need to change?

A:

You can change any class files that you want. You can add any classes that you want. You can add any methods that you want.

That said, most of your changes will probably be in the RRScheduler class. The methods in this class will be completely rewritten to implement the TSScheduler. You may want to add some of the methods that correspond to those in Solaris, for example tick(), update(), sleep(), wakeup(), and preempt().

You will probably make a small number of changes to Sim. For example, you will need to read the dispatch table in from a file and into a table in memory.

You will also need to add a few variables to the Job class. Most of the variables will be used for scheduling: the priority of the job, the timeleft in the current timeslice, the value of dispwait, and perhaps a flag designating state of the job (RUNNING, READY, or BLOCKED). You will also need a variable corresponding to the length of an I/O burst (see next paragraph). Of couse, you will also need to add corresponding methods to access these variables from other classes.

Finally, you will need to change the JobArrival class so that the duration of an I/O burst can be specified in the trace file. The duration of an I/O burst is currently a constant in Sim; this will now be a variable associated with each Job.

Q3:

In the current RR scheduler, the variable QUANTUM is used to determine the length of a time-slice. Is there a way we can leverage this functionality in our TS schedulers?

A:

Yes. In your versions of the TS schedulers, set QUANTUM equal to a clock tick in Solaris (i.e., 10ms). On every clock tick, the main loop in Sim can now call a method TS.tick(). This code will decrement the timeleft for the running process (i.e., the currentJob() on the CPU device); if the timeleft reaches zero, you should lower the priority of the job appropriately.

Q4:

Do you have any advice on how to implement the update() routine that runs once a second?

A:

You have two options.

1. You can add a new device very similar to the current Clock. This new device will create a new event every second. You can call your TS.update() method from the main loop of Sim.
2. You can have your new TS.tick() method track the number of 10ms ticks thathave gone by. When 1 second worth of ticks have gone by, you can call your TS.update().

Q5:

What format should we use for the dispatch table that we read in from a file?

A:

When you run "/usr/sbin/dispadmin -c TS -g" you will get output that looks like the following:

# Time Sharing Dispatcher Configuration
RES=1000
 
# ts_quantum  ts_tqexp  ts_slpret  ts_maxwait ts_lwait  PRIORITY LEVEL
       200         0        50           0        50        #     0
       200         0        50           0        50        #     1
       200         0        50           0        50        #     2
       200         ...

When you create your file containing the dispatch table, you should omit the first 4 lines of the output and start with the lines that form the actual table:

       200         0        50           0        50        #     0
       200         0        50           0        50        #     1
       200         0        50           0        50        #     2
       200         ...

Note that when you read in the table, you will want to divide the first column (the quantum specified in milliseconds) by the length of the clock tick (i.e., 10ms). This will simplify your implementation of the TS.tick() method.

Q6:

When should the dispwait variable of a process be cleared?

A:

The dispwait variable should be cleared in precisely three situations.

1. When a process finishes its timeslice.
2. When the update() routine runs and the process is labelled starving (i.e., when dispwait > maxwait).
3. When the process wakes after sleeping and dispwait > maxwait.

Q7:

Two questions regarding the update() routine. First, when we update dispwait for jobs, the notes said we should do this for "each" job in the system. Should we EXCLUDE the one currently running on CPU? Second, when we update dispwait once a second, we use a "unversal" clock to keep track of time for ALL JOBS. So if a job starts at 999ms, its dispwait gets updated to 1 after 1ms. Is it OK?

A:

Yes, you should exclude the one currently running on the CPU.

Yes, you should have just one update() routine for all jobs that runs once a second. The result is that a job could have its dispwait incremented after it has been in the system for only 1ms, as in your example.

Q8:

I have a question regarding the statistic (d) "average job waiting time" that we are to report. Does that mean the burst waiting time generated by the program you provided already, or it is the same waiting time we implemented for test starve condition?

A:

The average burst waiting time generated by the program is taken over all bursts, whereas I want the average waiting time taken over each job. This is probably what you implemented to show the starve condition.

Q9:

What is the completion time statistic?

A:

Completion time is the final time at which the workload completes; i.e., the elapsed time when the last job in the workload is done.