-
In round robin scheduling, if a higher priority process
arrives before the time quantum of the current process is up,
should we immediately interrupt the current process and let
the higher priority process run?
Yes.
-
In shortest remaining time next, if a process P1 finishes its
burst but, of all processes ready to run, P1 still has the
shortest next burst time, should we let P1 run again?
No. P1 should be excluded from the processes in contention.
- We are not simulating I/O burst times. Assume that a job is ready as
soon as it finishes
- Assume that a job exits after it has exhausted its CPU bursts.
- Each CPU burst should be of differing (randomized) duration, however
CPU bound jobs should have longer burst times (on average) than
I/O bound jobs.
- With round robin scheduling, if a process finishes a burst time
within the alotted time quantum, and still has another burst, does it
start on that burst until its time quantum is gone, or does it release
the cpu and wait for it's next turn to begin its next burst?
Wait for it's next turn to begin its next burst.
- For Shortest remaining time left is
the determination of "shortest" made by using the next burst time, or
is it made by using a summation of all remaining burst times?
Use next burst time.
- Are we to assume that the burst times in the trace file are
chronological?
Yes? They occur in sequence, one after another, in the order they
appear in the trace file.
- What constitutes an I/O Bound job: short burst times, but high
number of requests, if so then the inverse must be true for CPU bound
jobs?
Short burst times for I/O bound jobs. Long burst times for CPU bound
jobs. Number of bursts/requests is secondary.
- Ok, but I need more specific information!
Oh all right, 10 - 30 for I/O bound jobs and 70 - 90 for CPU bound
jobs.
- Will you use our trace file to test the simulation?
Yes. But I will also use my trace to test your simulation.
- Which java should I use?
You may set your path to include (as a prefix)
/usr/local/j2sdk1.4.0/bin
This will allow you to use java 1.4. We will be testing with Java 1.4
- What is response time?
Same as waiting time for this level of simulation.
- Should I predict the next burst time
You do not need to predict the next burst time. Simply use the next
burst time that you generated.
- What is the priority of a job?
Grad students need to model priority by using the additional priority
value in the trace file. Use priorities from 1 to 3 with 3 being
highest priority and 1, lowest. Trace files will contain the priority
field, but algorithms that do not deal with priority (undergrads)
should ignore this field.
- How many bursts?
1 - 20
- How many jobs or when do jobs stop arriving?
You should
have between 2 - 20 and there should be between 0 and (5 to 20) time
units between job arrivals. 50 * 20 = 1000 time units should be a
reasonable limit on when jobs stop arriving.
- Default output for trace file:
Should be standard output.
- By the same token, your simulation should
- be able to read the trace from standard input,
This allows us to pipe/redirect our trace file to your simulation.
- Please only use command line arguments. Do not prompt the user for
any input.
- Throughput Since the burst times are all multiples of the
time unit, if I measure throughput as (total jobs) / (total time), it
is a rather small number (e.g., ~0.001 or 0.005). I'm thinking of
measuring throughput as:
(total jobs) / (100 time units)
which gives more reasonable values, such as 1.22 or 5.03.
Is this OK? I'm thinking of doing this and mentioning it in my README
file. In the book, it discusses measuring throughput as jobs/hour or
jobs/second, but burst times would typically be much smaller than the
time quantum used as the denominator for throughput. That's why I
thought multiplying by 100 might be a good idea.
I agree. This is ok.
- ...