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.

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.

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.