Learn about the technologies behind the Internet with The TCP/IP Guide!
NOTE: Using robot software to mass-download the site degrades the server and is prohibited. See here for more.
Find The PC Guide helpful? Please consider a donation to The PC Guide Tip Jar. Visa/MC/Paypal accepted.
View over 750 of my fine art photos any time for free at DesktopScenes.com!

[ The PC Guide | Systems and Components Reference Guide | Hard Disk Drives | Construction and Operation of the Hard Disk | Hard Disk Logic Board ]

Multiple Command Control and Reordering

The IDE/ATA interface used on most PCs is generally limited to a single transaction outstanding on the interface at any given time. This means the hard disk can not only do just one thing at a time, it can't even keep track of what it needs to do next. It must be fed commands one at a time by the controller. In contrast, newer drives using the SCSI interface generally include the ability to handle multiple requests, up to a certain number. This advanced feature, sometimes called command queuing and reordering or multiple command queuing, is very useful for servers and other systems being used by multiple people (while its absence is generally not a problem for most single-user PCs equipped with IDE/ATA hardware.) You can read more about this feature here.

If the hard drive's logic circuitry receive multiple commands to read or write from the disk, it must process them and figure out where on the disk the data is for each request. Some requests may be filled from the internal cache; these would generally be filled immediately. For the remainder, the controller must decide in which order to perform them. Since random reads or writes on even the fastest hard disks take thousands of times longer than computing operations, this determination is very important to overall performance. There are probably dozens of different specific algorithms that could be used to decide which commands get fulfilled first. However, they generally fall into these three categories:

  • First In, First Out: The drive processes the requests in the order that the requests arrived. This is the "supermarket deli" algorithm: simple in both concept and implementation; but in the case of hard disks, poor in performance. In the deli, all the customers are standing in the same place; on the hard disk, the sectors to be read or written might be in very different areas, and processing them just based on which came first will result in no optimization whatsoever. Imagine a 100-story building with the elevator on the ground floor. A person on floor #77 presses the "Up" button, followed immediately by someone on floor #31, then floor #94, and then floor #20. Filling these requests in the order received would result in a lot of needless waiting around (especially by the poor guy on floor #20!)
  • Seek Time Optimization: The drive analyzes all outstanding requests, and reorders them based on their cylinder number, compared to the cylinder where the heads currently are located. This is seek time optimization, sometimes also called elevator seeking because it is designed to prevent needless swings of the head actuator across the surface of the disk, much the way a real elevator would sort the requests given in the example above to avoid wasteful up-and-down activity.
  • Access Time (Seek and Latency) Optimization: The problem with seek time optimization is that it doesn't take into account rotational latency. Two requests might be on cylinders that are very close to each other, but in very different places within the track; meanwhile, there might be a third sector that is a few cylinders further away but much closer overall to where the first request is. The most advanced logic boards in the newest drives will carefully analyze their requests and determine which to do first based on both how much time will be required to seek to the various sectors' cylinders, and how much time will elapse waiting for the data to rotate under the heads. This is often called multiple command reordering or multiple command optimization. Needless to say, this is much more complicated than regular elevator seeking, because the drive must know many more details about exactly where each sector is, and must understand its own performance attributes just as well. If the logic is too "aggressive" and the head takes longer to seek to a location than anticipated, it might miss the correct sector as the drive rotates, and have to wait for nearly a full rotation of the disk until that sector comes around again.

Quantum's version of command optimization is called "ORCA", as you can see
above. The diagram shows graphically what the idea is with this technology.
Note when comparing the two figures above, that on the one at right,
"Seek 3" has been "rotated" counter-clockwise a bit. That's significant: if you
applied "ORCA" to the figure at left, with "Seek 2" and "Seek 3" so close to
each other, it would probably not be possible to do them in the order "2, 3, 1"
because there wouldn't be enough time to change tracks before "Seek 3" rotated
past the head. If you tried, you'd end up doing worse than if you just did "2, 1, 3".
This is all part of what the algorithm has to figure out as part of its job.

Image Quantum Corporation
Image used with permission.

You may recall that I mentioned in the section on control circuitry that the importance of the drive's internal circuitry is typically under-appreciated. I said that this is generally because it is hard to "boil down" the differences between drives into a single metric, and because it is nearly impossible to get detailed information about the circuitry's internal logic. This section on multiple command handling provides a good illustration of this phenomenon. Two drives could have nearly-identical seek times, spindle speeds and transfer rates, but one could handle heavy access by multiple users much more gracefully if its algorithms were more efficient.

Next: Hard Disk Cache and Cache Circuitry

Home  -  Search  -  Topics  -  Up

The PC Guide (http://www.PCGuide.com)
Site Version: 2.2.0 - Version Date: April 17, 2001
Copyright 1997-2004 Charles M. Kozierok. All Rights Reserved.

Not responsible for any loss resulting from the use of this site.
Please read the Site Guide before using this material.
Custom Search