please see remarks embedded below.
Dick
----- Original Message -----
From: "Pete Turnbull" <pete_at_dunnington.u-net.com>
To: <classiccmp_at_classiccmp.org>
Sent: Sunday, April 08, 2001 3:45 AM
Subject: Re: ESDI drives
> On Apr 7, 23:31, Tony Duell wrote:
>
> > Incidentally, is the ESDI spec
<snip>
> >
> > I wondered about that, too (it was an obvious way for a twist to be able
> > to swap drives 1 and 2). I assume from this that the drive select lines
> > are not used as data lines for anything else, then (unlike SCSI, say,
> > where the same 8 lines are used both to select a particular unit and to
> > transfer commands and data).
>
> No, it's a pretty low-level interface, like ST506/412. I read somewhere
> that it was designed as an enhanced/faster ST412 interface, possibly by
> Maxtor and Miniscribe, and I think Maxtor used to have some information on
> their website. All I can find now, though, is a line in their glossary.
>
It's not low-level in the sense in which ST506/412 works, in that the drive
doesn't rely on the controller to modulate/demodulate the data stream, nor does
it rely on the controller to micro-control the head positioning. It responds to
high-level commands, e.g. "format the track" and executes them as determined by
drive-resident firmware rather than a controller-determined protocol, more or
less as does the SCSI, though it doesn't buffer the data and it doesn't do its
own error correction. Though the transfer rates are pretty high, because the
controller does so much of the work, and because raw data rather than processed
data flows between drive and controller, parallelism between drives is not
possible.
I once attended a convention at which I recall a prominent rotating memory
systems expert characterizing the ESDI (which I was using in a uVAX-II-based
military oriented system, at the behest of the fellows at JPL) who characterized
it (ESDI) as a "next-step" after SMD. This did, at the time, make some sense.
In the uVAX-II/MSCP environment, we found that both ESDI and SCSI were capable
of higher transfer rates than the OS could consume in normal operation, but,
when pressed, ESDI, though it had higher raw transfer rates than what SCSI would
do, was outperformed in every respect by SCSI when put to a discrete test. SCSI
transferred data faster, in the aggregate, in a system with two drives, and
MSCP, though it did quite well with either interface, seemed to utilize SCSI
much better than the PC did, in that it exploited disconnect/reconnect, command
queueing, etc, in a way that enabled inter-device communication, etc, so as to
perform MUCH better than ESDI. Moreover, the then-new SCSI version of the
MAXTOR 4380E which was what we'd been using, cost a flat $1k less than the ESDI
version, and the EMULEX SCSI adapter cost $1k less than the EMULEX ESDI
controller we were using as well. With two drives per system, and combined with
the fact that the SCSI adapter had to be there for the MO drives we were
required to use in place of the usual TK50's, it was not a hard choice from an
economic standpoint. Presenting the choice in such a blatant and compelling
way, however, got me fired (temporarily) from my position on that project. It
was not a good thing to do from a political perspective ... <sigh> ...
I was very impressed with the uVAX implementation of these two interfaces. I
could not make the PC/AT perform as the uVAX-II disk subsystem did, even though
the PC/AT (at 25 MHz) ran rings around the uVAX-II in discrete performance
tests. Clearly, both SCSI and ESDI benefit greatly from a well-thought-out
implementation. Apparently the PC lacked that.
>
> --
>
> Pete Peter Turnbull
> Network Manager
> Dept. of Computer Science
> University of York
>
>
Received on Sun Apr 08 2001 - 10:06:28 BST