The performance implications of the ISA bus

[Piercarlo Grandi]

On 11 Dec 90 15:37:41 GMT, rreiner at yunexus.YorkU.CA (Richard Reiner) said:

pcg> just using two ESDI controllers, one per each disk, will give
pcg> tremendous improvements [because of multi-threaded operation]

rreiner> What about using SCSI equipment?  Do there exist SCSI host adaptors
rreiner> for the ISA bus which support multi-threaded operation?

Ah yes, the common recommendation is the Adaptec Host Adapter 154xB. It
sings it dances, it is a floor wax and a dessert topping. Not only it is
multithreaded, it does bus mastering without CPU involvement, does DMA
with its won fast DMA technology, and does scatter/gather in hardware
with command chaining. In other words, it is more of an IO coprocessor
than a crude disk controller. The ISC HPDD exploits all its wonderful
aspects.

The only defect of the 1542 seems to be fairly long operation setup
times, in the millisecond range, but I don't thing this is terribly
important, unless you attach solid state disks to your SCSI bus.

Other SCSI controllers (OMTI, Future Domain, WD FASST) may be as
sophisticated, but I have no certain data. The Adaptec seems to be the
most popular, and can be bought fairly cheaply from Tandy. Other drivers
may be able to exploit all its wonders, (the Esix one maybe), but again
I have no details.

rreiner> And what about track-buffering ESDI controllers?

A word of caution here: I have been reminded by William Bogstad by
e-mail that there is another reason (that I had already mentioned myself
long ago in comp.unix.i386) for which a multithreded controller is
preferable to two ESDI ones. ESDI discs cannot do command chaining,
which means that they scatter/gather has to be interrupt driven by the
UNXI disc driver, not by the controller. This means that as the IO
operations per second increase interupt processing overhead also
increases, and can be come quite severe, because disk interrupt
processing is a very high overhead activity in all 386 Unixes I know
(not many). This obscene overhead could be largely obviated, like in
some PDP/VAX drivers, with an interrupt processing fastpath, called
pseudo-DMA in software. Maybe some 386 Unix vendor has already
implemented it, but I am not aware of any.

It can take several thousand instructions (milliseconds!)  for an
interrupt to be processed by a 386 Unix disk driver, and for a new block
operation to be reissued. With IO operation rates of a several dozen per
second on 4 MIPS processors this can represent a significant percentage
of CPU time. For very high IO loads with many fast discs, hardware
scatter/gather is very important.

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.

The zero-seek-time property of three well scheduled moving arm discs
moreover must be carefully understood -- it says that you get the same
number of IO operations per second from 3 arms moving in parallel over
3 discs of X capacity, as you get out of a single disc with fixed heads
and 3X capacity, *if* there is enough load.

Note that this number of IO operations per second is lower than the
number of IO operations per second from 3 discs with fixed arms, because
there are two extra transfer channels than for a single disc with 3X
capacity and a fixed arms. Still the speedup is impressive (but you must
balance the load across the three discs!).
--
Piercarlo Grandi                   | ARPA: pcg%uk.ac.aber.cs at nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg at cs.aber.ac.uk