Hard drive simulator

Learning Objective(s)

  1. Be able to code stack, queues, and priority queues
  2. Create different types of testing data to different types of situations
  3. Introduction to optimization of a hard drive

Overview of the Challenge

To optimize the hard drive, the main concern in the movement of the read/write head from different tracks. The most optimized solution will get all possible request in a increasing manner. This is similar to how a good elevator will work. Your job is not to developed an optimized scheduling of track requests, but to see how it performs with three different data structures (stacks, queues, and priority queues) to see which might perform better. You need to track the number of times the read/write head changes direction.
Example If the requests where handled in the following order: 2, 5, 8, 4, 3, 6. It would change directions two times (one from increasing to decreasing (8 to 4) and then one from decreasing to increasing (3 to 6).

Specifics:

  • You need to create your own data files (reading in integers, one per line).
  • A -1 indicates that all currently queued up requests should be processed before reading any more.
  • The drive should be initially loaded with three requests (less if -1 or eof is encountered) before processing any.
  • After processing one request (i.e. the next track), the next request (if not eof or not -1) should be added to the waiting list.
  • Output each track number as it is processed.
  • When done, output the number of changes in directions made.
  • Run with the same input for a stack and a queue
  • You must use an array to implement the queue
  • You must use a linked list to implement the stack.
  • Your implementations of stacks and queues need to handle faults by correctly throwing exceptions.

Design components

Refer to the software design/development report for additional details. For the design component of this lab, pay special attention to:
  • A quality set of testing data. This should include many different types of situations as possible and the results you expect
  • Try to have a somewhat accurate estimate of how long you think it will take to code your design.
  • An estimation of which data type is better under which situations.

Optional improvements

Any/all of these can be added to your program for extra credit. But do not attempt them until your program (including the write up) is complete and receiving at least a 90%. Extra credit will only be given to those programs that receive at least a 90% on all the required work. It is much more important to do the required work well than to do the extra credit. Typically, extra credit work is also done on your own with limited (typically no) help from the instructor. The options are listed in order of importance. While you may implement any/all in any order, the order listed will focus you on the more important items first
  1. Add the use of priority queues. Have two queues. one that is "increasing" and one that is "decreasing" (hint: negative numbers). If the next track to be added is helpful in your current direction, add it to that priority queue, otherwise added to the second one. When you change directions swap around the priority queues.
  2. Track when a track request went in (the sequence number) and when it came out. The difference is "how long it waited". Analyze the results based on the average and maximum wait in addition to the number of times it changes directions.
  3. Have the file be specified at the command line
Edit | Attach | Watch | Print version | History: r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r1 - 2021-08-05 - cathybareiss
 
  • Edit
  • Attach
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2026 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback