[1468] in linux-scsi channel archive
Re: Disk array latency theory (was: EATA performance issues)
daemon@ATHENA.MIT.EDU (Dario_Ballabio@milano.europe.dg.co)
Tue Feb 25 09:13:43 1997
Date: Tue, 25 Feb 1997 15:04:50 +0100
From: Dario_Ballabio@milano.europe.dg.com
To: linux-scsi@vger.rutgers.edu, mingo@pc5829.hil.siemens.at
I just finished to test rev. 3.00 of the EATA driver, which includes
an elevator sorting functionality. Basically I queue commands internally
into the driver until there is an active command on a specific device.
When this last command completes, I have a good indication about where
the disk head is. According to this data I sort (or reverse sort)
the queued commands in order to minimize the seek distance.
The driver calculates the average seek distance (both native and
sorted) and the results are in agreement with the theoric (Q-1)/2
factor (for random operations).
Enclosed a portion of the new documentation from the rev. 3.00 EATA
driver.
db
%UATTACH
*
* ----------------------------------------------------------------------------
* In this implementation, linked commands are designed to work with any DISK
* or CD-ROM, since this linking has only the intent of clustering (time-wise)
* and reordering by elevator sorting commands directed to each device,
* without any relation with the actual SCSI protocol between the controller
* and the device.
* If Q is the queue depth reported at boot time for each device (also named
* cmds/lun) and Q > 2, whenever there is already an active command to the
* device all other commands to the same device (up to Q-1) are kept waiting
* in the elevator sorting queue. When the active command completes, the
* commands in this queue are sorted by sector address. The sort is chosen
* between increasing or decreasing by minimizing the seek distance between
* the sector of the commands just completed and the sector of the first
* command in the list to be sorted.
* Trivial math assures that if there are (Q-1) outstanding request for
* random seeks over S sectors, the unsorted average seek distance is S/2,
* while the sorted average seek distance is S/(Q-1). The seek distance is
* hence divided by a factor (Q-1)/2.
* The above pure geometric remarks are valid in all cases and the
* driver effectively reduces the seek distance by the predicted factor
* when there are Q concurrent read i/o operations on the device, but this
* does not necessarily results in a noticeable performance improvement:
* your mileage may vary....
*
* Note: command reordering inside a batch of queued commands could cause
* wrong results only if there is at least one write request and the
* intersection (sector-wise) of all requests is not empty.
* When the driver detects a batch including overlapping requests
* (a really rare event) strict serial (pid) order is enforced.
* ----------------------------------------------------------------------------
*
