The performance implications of the ISA bus

[John Macdonald]

In article <PCG.90Dec12195835 at odin.cs.aber.ac.uk> pcg at cs.aber.ac.uk (Piercarlo Grandi) writes:
|rreiner> Would their advantages go away if they were used in the setup
|rreiner> you suggest (since you claim that one would get effectively
|rreiner> near-zero seek times anyway)?
|
|Track buffering is not a property of ESDI controllers alone; some
|popular RLL controllers also have track buffering. Track buffering reads
|an entire track when you read or write a sector on that track. This is
|only a win if you access consecutively several sectors in the same
|track, otherwise it is a lose because it forces you to wait for an
|entire revolution to read a sector, when on average only a third/half
|would be enough. With old style filesystems, which are fragmented fairly
|easily, this is usually not a win, especially for writes; I have turned
|off track buffering on my RLL controller. It is instead a definite win
|if you use the various styles of Fast File System, as they usually
|succeed in keeping logically consecutive sectors physically contiguous
|as well, and in doing multi sector requests.
|
|Note that track buffering only influences rotational latency, not seek
|latency.

It is possible to set up a controller to give most of the benefit
of track buffering without any possible loss.  Have the controller
do the following when attempting to read a sector: seek to the
right track, start reading sectors.  When the desired sector has
been read process it (send it to CPU using the appropriate DMA and
so on and then interrupt the CPU to terminate the IO; while this
is being done continue to read the track and save each sector that
is read into the track buffer.  Keep a record of which sectors have
been read and which haven't.  Whenever the CPU's device driver
handles the IO completion it will likely issue another request.
When a request comes to the controller, check to see if it can
be satisfied from any available buffered track.  If so, do that
and don't interfere with any disk reading that is still going
on filling a track buffer.  If not, terminate any ongoing track
buffer activity for a different track and seek to the desired
track, and start buffering.  When the background processing is
able to finish reading a track buffer and there is still no new
request that requires a real disk access, then additional background
activity can be done (complete filling a track buffer that has been
partially filled, read a new track when many of the sectors in the
previous track have been used, write out any buffered changed
sectors if write-through is not being used, etc.).  Since this
procedure returns a result as soon as it is available, and start
to process a new request as soon as it is issued, there is no loss;
it is just that there is the potential for using the sectors that
come under the read head during rotational latency, and in using
the time between host requests, and in using the time saved by
filling a host request from a track buffer.

Off hand, I don't know whether any particular disk controller
uses this algorithm, but I wouldn't be surprised if one did.
It does require that the controller be able to do some activities
simultaneously (DMA, IO completion, and new activity startup with
the host; all at the same time as IO processing to the disk.)
-- 
Cure the common code...                      | John Macdonald
...Ban Basic      - Christine Linge          |   jmm at eci386