Keep in mind that the most important part of this project is running the program, gathering statistics and making significant observations, based on these results, about the topics we have covered throughout the semester - such as locality, page size, throughput, turnaround time, etc.  As mentioned last week, one of your classmates has gotten some very interesting results about the relative importance of choice of page size and memory size.   Specifically, he found that choosing the best page size gave better overall results than doubling the total amount of system RAM!

    This means that at some point you may need to invoke the Kenny Rogers Principle ["you have to know when to hold 'em, know when to fold 'em, etc."].  Even if your program is not 100% correct, it may be time to "fold 'em" and move on to the gathering information phase of your work.

     Keep in mind, also, that there are many factors that can create differences in precise sysclock times, frames chosen for replacement, etc.  - factors such as placement of jobs on the ReadyQ, operation of the modClock pointer, setting of reference, modified and resident bits, etc.  An important example is the order in which page frames are given back when a job completes execution.  Or, more precisely, the order in which the page frames of such a job are placed on the Avail Q.

     And, perhaps most important of all, the sample runs I have posted are only to serve as a guide, as something to let you know whether you are in the ball park.  It is very possible that there are undiscovered errors.  For example, why the simulation takes so many iterations is still not clear.  It may be due to a bug in the program.