eternalearth888/csci442_project03

csci442 | Operating Systems | fall 2013 | camp | project03

#csci442 | fall 2013 | camp | project03 ##TEAM

• Maria Deslis @eternalearth888
  • HOURS:
    • Intermediate One: 25.5
    • Intermediate Two: 8
• Mykala Miller @mymiller
  • HOURS:
    • Intermediate One: 25.5
    • Intermediate Two: 13
• Austin Thompson @authompson
  • HOURS:
    • Intermediate One: 25.5
    • Intermediate Two: 15
• Joseph Cirone @jcirone
  • HOURS:
    • Intermediate One: 25.5
    • Intermediate Two: 11

###Unusual/Interesting Features N/A

###Hardest part of the assignment Retrieving the process table, specifically using the function sys_vircopy()

###Any additional comments regarding the assignment First intermediate task took WAY too long; information & tutorials were insufficient

###How we modified Minix to retrieve a copy of the process table and how you implemented SPN scheduling PROCESS TABLE:

First, we implemented a system call to the PM server. We did this by following the tutorial given to us in the project pdf and on piazza. We neglected doing the library file and instead called the system call directly within our program. We then implemented a task call to the schedule server using a similar process that was used for creating the system call. We defined a new constant for the switch statement in main.c for the scheduling server; inside this case statement we called OSSendPTab where we retrieved the process table via the predefined kernel call and attempted to copy it up to the user level using sys_vircopy(). This is where we were unable to complete the first intermediate due to complications and decided to turn the first intermediate as is.

SPN SCHEDULING:

Inside OSSendPTab we got the endpoints and other process information for the processes generated by the proc function and stored them in the sjf-struct array. Inside schedule.c, we modified the schedule_process function to calculate the predicted burst time of the process that has been preempted or blocked. We then sorted the burst times and selected the one with the shortest predicted burst time. We used the kernel call qptab to dequeue and enqueue this process. We modified com.c inside the OSPEX directory to run the simulation without the GUI allowing printf statements at the server level to be displayed in the console. We then printed the predicted burst times for all the simulated processes and printed the index of the process that we chose.

###Description of how team proved that SPN was implemented ####(see SCREENSHOTS folders) Within the screenshots, the list of predicted burst times is displayed for a certain step within the simulation, along with other debugging information. We also indicate which process was chose to be dequeued and enqueued within the kernel

###Results of Performance Analysis We examined the 50th snapshot on the Simulation for both the original algorithm and the one we implemented. For the original implementation, two processes were consistently in the 13th and 14th queue. For our implementation, we had 4-6 processes remaining in the 7th and 8th queues.

This is consistent with our understanding of SPN, because SPN strongly favors I/O bound processes, which generate shorter predicted burst times. This is consistent with the processes remaining in the higher-priority queues, because the I/O bound processes wouldn't be demoted to lower-priority queues in the same fashion that processor-bound processes would be, and the processor-bound processes wouldn't be executed as often, so they wouldn't be moved to the lower-priority queues.

####Pros/Cons Of Two Algorithms SPN (with Feedback and Priority) compared against Multi-Level Feedback Queue (Round-Robin with Prioirty):

• Pros:
  • Shorter processes are executed quicker. This improves the normalized turnaround time, and minimizes the average wait time.
  • I/O bound processes are favored. This improves resource utilization.
• Cons:
  • Longer processes tend to be starved of resources.
  • Not fair to processor-bound processes.
  • Has a higher overhead