Frequently Asked Questions about HW1 (from Spring 2005)
------------------------------------

Q1: How do you calculate "the mean number of customers in the system (in the
queue + in service)"

Let N(t) be the number of in the system (in the queue + in service) at 
time t. If N(t) is a continuous function of t, then the mean number of 
customers in the system between time [T1, T2] is 

	N0 = integral{from T1 to T2, N(t)dt}/(T2 - T1)       	(1)

Now in our simulation, since N(t) is discrete, the integral becomes 
weighted sum. Let {t0, t1, ..., tn} be the moments when N(t) changes,
where t0 = T1, tn = T2. Then

	N0 = suml{i = 1 to n, N(t)(ti - t(i-1))}/(T2 - T1)	(2)



Q2: Should a job be counted towards the Mean Number of Jobs during its
overhead time?

A job should be counted towards the Mean Number of Jobs right after it 
arrives at the system.


Q3: Is the print out going to be graded by an autograder? If so, can
someone please specify the format in more detail (i.e. tab-delimited
or space-delimited)?

This assignment will not be graded by autograder and there is no
specific format requirement. Just make the output clear and follow
instructions from the homework. Also note that the reader will look
at your code so make sure it is clean and well commented.


Q4: In addition to generating and using our own times, does our
program have to be able to deal with your supplied time files (other
than debugging purposes)?

Yes, your program have to be able to deal with supplied time files, as 
specified in the homework.


Q5: Time slice

Both RR and SET alorithms use quantum or timeslice. For simulating 
these two algorithms, it is NOT a good idea to use a periodic timer.
This is because these algorithms require that once you start running 
a job, you should let it consume all the quantum unless it finishes 
first. If the running is interrupted by arrival of new jobs, you 
should process the new arrivals first (putting them into the job 
queue) and resume the CURRENT job. You need to postpone the ending 
of its quantum because the system spent time not servicing this job. 
This means the clock that interrupts at the end of each quantum is
not ticking at constant rate. It is much easier to use an "alarm 
clock": when you start a job, set an alarm clock that will go off
at the end of the quantum. You then update this alarm clock as you 
handle other events.



Q6: Overhead Handling

An overhead X can be considered to consists of two parts:

X/2: putting a job into the job queue.
X/2: starting a job

Whenever a job arrives, the system needs to put it into the job 
queue first, even if it is the one that will run next. Note that 
an overhead is not atomic. When the system is in an ovverhead and a
new job arrives, the system needs to process the new job by putting
it into the job queue and checking if it should be the next to run.
This processing will cause its own overhead which is not atomic 
either. One way to handle this is just to treat an overhead as 
another job that has its own service time (X). If it is interrupted, 
you need to reschedule it as you would with an interrupted job. But 
now you need a place to store these "interrupted overhead" so that 
you can resume them later in the right order, just like a jobQ is a 
place for waiting jobs. Something like a stack should be the right 
data structure. Note two things: (1) while in an overhead, your 
system is in a special state and your simulation needs to reflect 
that and (2) the service time of an overhead may change while it 
is waiting in the stack because you may need to switch jobs. So X 
may become X/2 (you decided to just put the job into jobQ). This 
gets complicated, especially when you have already spent over X/2 
on that overhead when it was interrupted. If so you can consider 
this overhead be done.