ESDI vs SCSI

[tif at cpe.UUCP]

>Written 10:32 am  Apr 13, 1989 by athena1.UUCP!williamt in cpe:comp.unix.xenix
>In article <5436 at lynx.UUCP> m5 at lynx.UUCP (Mike McNally) writes:
>>The CDC Wren V drives we've used here can (with 64K requests) sustain about
>>1.2 Mbytes/sec.  That's on a 20 Mhz. 386 AT.  The ESDI drives with WD
>>controllers only do about 600K/sec.   Intelligent SCSI drives support a
>>variable number of sectors per track, so one gets more out of the drive.
>>They also do automatic bad block remapping.  Many have integral RAM
>>caches.
>3) Last time I looked at the AT bios it didn't use DMA in the disk
>routines.  So it really isn't a factor.

Who uses a BIOS?

>5) As for SCSI controllers supporting variable number of sectors per track,
>that is only in the interface presented to the user (computer).  Since
>the SCSI controllers have intelligence in them, they can remap the physical
>sectors in whatever fashion they choose.  This does not change the
>actual physical number of sectors/track, the spin rate, nor the final
>maximum transfer rate.  We evaluated a couple SCSI drives at my last
>job, and several of them could present 63 sectors/track to the BIOS so that
>DOS could use disks that had > 1023 tracks (the BIOS doesn't support
>more than 1023 tracks or greater than 63 sectors/track).  Presenting 63
>sectors per track didn't physically change the media to allow greater
>sector packing.  The transfer rate was the same as at the lower 
>sectors per track (around 30 something...I believe).

You completely misunderstand the SCSI concept.  INSIDE SCSI there is
no such thing as cyls, heads, and sectors, just block numbers.  But
DOS (and DOS-oids) can't handle that.  The SCSI adapter (rather than
the drive) fabricates those numbers to keep DOS (and DOS-oids) happy.
Tandy offers an upgrade BIOS to their SCSI adapter that presents the
drive as having 64 heads so even DOS can use BIG SCSI drives.  Xenix
actually handles everything internally in block numbers, but when it
gets an error it does calculations to come up with pseudo-cyl/hd/sec
numbers for the DOS-oids to read!

When Mike McNally said "variable number of sectors per track," he was
talking about different numbers of sectors on different tracks.  Since
there is more linear space available on the outer cylinders of a platter
it makes sense for a SCSI drive to put more information there.  The
drive also doesn't have to giveup the inner cylinders just because they
don't have enough linear space to support nn sectors.  And "yes," not
only is it feasible, but many drives do it.  That's one way to come up
with a 768 Megabyte drive.

And since drive manufacturers realize that the transfer speed is tied
to the linear speed of the head, some are in the process of implementing
two heads reading in parallell.  Actually there is no reason to adhere
to the same speed of revolution either, but I think all the manufacturers
still do.

>6) Yes, it is useful to have the SCSI port if you have a need or use
>for it.  But most people don't.  I had a friend ...

Can you say "ex-pan-si-bil-i-ty"?  Aww, who needs it!
(768 * 7 * 2 = ?, why bother, it's more than I'll ever need)

>7) Be careful about how you measure disk xfer speed.  I have seen 'coretest'
>be totally fooled by one controller that kept an on board cache into believing
>it could xfer over 5Meg/sec on a 386.  Some tests also seem to be less
>than reliable on ESDI drives because it is apparently common or standard
>to include a track buffer.

Isn't that part of the purchasing decision too?  Are you interested in
the system performance, or how fast does that durn drive really spin,
how many sectors does it really have, how fast can it really move that
head, etc.?  Since the intelligence is on the drive in a SCSI system,
it is now typical for a drive to have a modest amount of cache that is
tuned specifically for the drive's geometry and performance.  Some even
allow the customer to tune it for his application.  Isn't that the way
it should be?

BTW, "slower"??  How about 10ms average access to 300Meg?

			Paul Chamberlain
			Computer Product Engineering, Tandy Corp.
			{killer | texbell}!cpe!tif