[comp.unix.i386] SCSI vs ESDI

dag@fciva.FRANKLIN.COM (Daniel A. Graifer) (05/25/90)

In article <1945@east.East.Sun.COM> gsteckel@diag2.East.Sun.COM (Geoff Steckel - Sun BOS Software) writes:
>[...list of attributes of ESDI & SCSI systems...]
>SCSI
>	multiple masters (can share devices)
>[...discussion...]
>One SCSI host adapter on that system talks to [...]
>and could be connected to another CPU for a fake network. [...]
>	geoff steckel (gwes@wjh12.harvard.EDU)
>			(...!husc6!wjh12!omnivor!gws)

I didn't know SCSI supported multiple masters.  I've heard of a Macintosh 
product that connected two Mac's via their SCSI ports, but I thought there
were two SCSI buses and a gateway in that system, not one bus.

We have two SCSI bus machines here each with >500MB of disk.  We also have
one Excebyte 2.2GB SCSI tape system.  We can only do unattended backups
overnight on one machine per night.  Is it hard to get a SCSI device like
a tape backup system to talk to two hosts?  How is contention handled?  If
I have a bus that looks like this:

    [SYSA]-[DSKA0]-[DSKA1]-[TAPE]-[DSKB1]-[DSKB0]-[SYSB]

How do I keep SYSA from trying to control the DSKB?s ?  (Actually, guess this
wont work for me anyways.  Each machine has a QIC tape on it as well. That's
too many SCSI addresses (4/system + Exebyte). Maybe someday we'll get SCSI2!).

If this wont work, does anybody make a box that allows one device to sit on
two SCSI buses, and handles the contention between them?  You could just
simulate DEVICE-NOT-READY when the device was in-use by the other system.

Thanks in advance?
Dan

-- 
Daniel A. Graifer			Franklin Mortgage Capital Corporation
uunet!dag@fmccva.franklin.com		7900 Westpark Drive, Suite A130
(703)448-3300				McLean, VA  22102

Smyers.S@AppleLink.Apple.COM (Scott Smyers) (05/25/90)

In article <1945@east.East.Sun.COM> gsteckel@diag2.East.Sun.COM (Geoff 
Steckel - Sun BOS Software) writes:
> SCSI:
>         medium level physical and virtual connection
>         can connect to disks, printers, CPUs, tapes, etc.
>         does not need to know about physical data layout
>         accomodates widely varying data rates
>         parallel data transfer
>             (8 bits - SCSI-1) max 5 MB/sec
>             (16 (+?) bits - SCSI-2) max 10 (+?) MB/sec
>         high level (formatted messages) command/response
>         devices may relinquish/reacquire bus to share it
>         multiple masters (can share devices)
>         eight controllers/adapters (256 on SCSI-2) per bus
>         eight (more on SCSI-2) subunits per controller

SCSI-2 can go up to 10 MHz at either 8, 16 or 32 bits wide.  This gives a 
maximum transfer rate of 10 MB/sec (8 bits), 20 MB/sec (16 bits) or 40 
MB/sec (32 bits).

Also, both SCSI-1 and SCSI-2 can have up to 8 devices connected to the 
same bus, and each device can have up to 8 logical units (LUN's).  If your 
CPU is one device, it can talk to 7 X 8 or 56 disks, tapes, etc on a 
single SCSI bus.  There was work on the SCSI-2 committee to increase the 
number of devices to 16 and/or the number of LUNs per device to 16, but I 
don't think these increases are in the final SCSI-2 spec.

------------------------------
The ideas and information presented here are my own, not Apple's.

barton@holston.UUCP (Barton A. Fisk) (05/28/90)

In article <1990May23.151746.18784@cbnewsm.att.com>, dab@cbnewsm.att.com (david.a.berk) writes:
> Subject line says it all, which is superior ?
> 

I think SCSI will pay off for you if you:

[from PW]

1. Want a single system interface that can connect to
   multiple disk drives, optical drives, scanners, printers,
   and other periphs.

2. Want to make it easier to add larger faster drives with
   innovative features.
   (this is absolutely true, as yesterday we added a 333meg
    Maxtor to a system and it was just about plug-and-go,
    not formatting is NICE!!)

3. Regularly access large files and tranfer large blocks.
   [makes SCSI overhead less of an issue, however some
    hardware makers (NCR is one) has employed a processor
    to offload the SCSI overhead (actually SCSI-2).
 4. Choose multiple smaller drives rather than one large
     one.

From working with SCSI, I especially appreciate #2. 

Hope this helps.
Barton Fisk     
  
-- 
uucp: holston!barton

keithe@tekgvs.LABS.TEK.COM (Keith Ericson) (06/02/90)

In article <1990May23.151746.18784@cbnewsm.att.com> dab@cbnewsm.att.com (david.a.berk) writes:
>Subject line says it all, which is superior ?
>
>
Depends on which one you put on top... :-)

From my experience they're essentially interchangeable; I'd be happy to have
either in my home computer (I have an RLL system currently).  It gets down
to which (whose) controler you're gonna use.  I prefer Adaptec for both
(plus RLL, but we're not here to talk about that...).

ESDI might be favored if you're running UNIX (I mean this _is_ comp.unix.i386)
since the ESDI controllers are more fully supported.  So far the UNIXes I've
played with support "only" the Adaptec (fine with me) and the Future Domain
for SCSI; but ESDI doesn't require a separate driver because of its register
compatibility (did I get that correct?).  

kEITHe

billbr@xstor.UUCP (Bill Brothers) (06/05/90)

In article <1990May23.151746.18784@cbnewsm.att.com> dab@cbnewsm.att.com (david.a.berk) writes:
>Subject line says it all, which is superior ?
>
>
>Dave Berk
>att!emdbl1!dab

Although the question is similar to "Which is better - single or married?",
I will try to put some of the good/bad info so a reasonable person could
further find facts and make a decision...

IF you are only ever going to run one disk drive on a single-tasking OS,
your answer is fairly clear -- ESDI. Otherwise, the answer is -- cloudy.

At somewhere around two drives and somewhere around 10 concurrent
processes, SCSI gets faster than ESDI. This break-even point can be
calculated if the EXACT application mix is known. The break-even
point is a function of when the paypack of disconnect-reconnect is
greater than the overhead of the SCSI structure. Another variable
thrown into the fray for fun has to do with how intelligent your
host adapter is and etc. etc.

My personal belief is that for simple systems that will never outgrow
one disk, ESDI or IDE is fine. However, for more complex systems that
will need more and more storage, mirroring, fault-tolerance, or other
advanced features, SCSI is definately the winning side.

Remember, people yelling "tastes greate/less filling" may both be
right...

Bill Brothers
Product Engineering Mgr.
Storage Dimensions, Inc.
Voice (408) 379-0300
billbr@xstor.UUCP or uucp!xstor!billbr

src@scuzzy.uucp (Source Admin) (06/13/90)

especially on unix (or other multiuser/tasking systems scsi is a win when:
- the scsi adapter is clever (==has its own cpu, ram etc)
  and is a DMA bus master that copies data by iself,
  thereby offloading the main cpu a lot. also the disks
  can work all at the same time.
- you have two or better more disks (and a streamer perhaps)
  preferably with cache/read-ahead/request queues
- concurrent disk intensive processes run (said before)
- the organization is good.

for example my system looks like this:

/         (/dev/dsk/0s1    ):    44082 blocks     8709 i-nodes
/dos      (/dev/dsk/0p1    ):    42964 blocks    65535 i-nodes
/usr      (/dev/dsk/0s3    ):    83244 blocks    31665 i-nodes
/usr2     (/dev/dsk/0s4    ):   179064 blocks    54477 i-nodes
(5MB swap space on disk 0)
/tmp      (/dev/dsk/1s1    ):    49166 blocks    13791 i-nodes
(15MB swap space on disk 1)
/usr/tmp  (/dev/dsk/2s3    ):     3978 blocks      506 i-nodes
/usr/spool (/dev/dsk/2s4    ):    34236 blocks    34681 i-nodes

what's happening on my machine is:
- i have all binaries and nonchanging things on disk 0
- i compile everything on disk 1
- usenet news are on disk 2
- the compiler (gcc) uses /usr/tmp on disk 2
- swapping/paging uses both disk 0 and disk 1 evenly

thus disk intensive actions like compiling don't cause long seeks.
(one disk reads compiler, 'nother r/w's source, third r/w's temp files)
especially unpacking news in the background is a disk hog, so having
a disk for /usr/spool is a real win.
-- 
Heiko Blume		blume@scuzzy.UUCP	FAX   (+49 30) 882 50 65
Kottbusser Damm 28	blume@netmbx.UUCP	VOICE (+49 30) 691 88 93
D-1000 Berlin 61				TELEX 184174 intro d