Project 3 { Device Management Solution





What to do.         Implement the Devices module of OSP2.


The project     les are found on Blackboard in the Assignments section.


Details of what you are supposed to do are provided in the OSP2 documentation (the chapter on device management). It is required that you implement the following scheduling strategy:


Initially there is one queue of I/O requests.


When the device starts processing the rst request in that queue, the queue is closed and any subsequent I/O requests are added to another queue.


When the device is done with the rst queue, it switches to the second. That second queue is then closed and new requests go into a third queue, etc.


Note: This does not mean your implementation should use an unbounded number of queues. The above is a description of the desired behavior, not an implementation guideline.


Within each queue, requests are processed using SSTF (shortest seek time  rst).


Your objective in this project is to get your implementation to run under OSP2 without errors and warnings with the parameter les that appear in the Misc subdirectory (the les with the


.osp extension). As explained previously, occasional errors (every 5-10th run) should not be a cause for concern due to some synchronization issues in OSP2.



Statistics. Compare and explain your statistics with respect to those produced by Demo.jar (Demo.jar uses the FIFO algorithm). The statistics of interest are:


Total number of tracks swept on each device.


Average number of tracks swept per I/O request. Average turnaround time for I/O requests.


System throughput.

These statistics are part of the snapshots in the  le OSP.log, which is produced when OSP2 runs.


The meaning of these statistics is explained both in the textbook and in the OSP2 manual.



Important notice on the use of Git. You must use Git to maintain your project les and you must make frequent commits to your repository. The Git repository must be in Github classroom. Follow this link to create a repository in this course’s classroom for Project 3:


After a few clicks you will get a repository named cse306-project-3-YourGuthubId. The repos-itory will automatically become private and you should not attempt to change that.


We will be checking your repository and your commit logs to make sure that substantial activity has been taking place over a period of time. If there are less than 4 nontrivial commits, signi cant penalty will apply.


Otherwise, same requirements to your code as in Project 1.



How to submit. Zip-up your main repository branch and submit the zip le via Blackboard. Github has a button for that: Clone or download/Download ZIP. Normally, the zip le will have a top folder with a name like cse306-project-3-YourGuthubId-master, but if not then make sure that your submitted zip le has a top folder with such a name. Do not forget to include your name and Student Id in the program source- les. Do not submit paper-based material.


This project is to be done individually. Each source     le should include the following pledge:


I pledge my honor that all parts of this project were done by me individ-ually, without collaboration with anyone, and without consulting external sources that help with similar projects.





















error: Content is protected !!