Re: WinMac Digest #224 - 02/11/99 -- [WinMac] SCSI Voodoo


Dan Schwartz(expresso[at]snip.net)
Fri, 12 Feb 1999 11:40:35 -0500


        Kelly,

        Actually, it's not the device or the ID that counts in a SCSI chain. It
all boils down to two issues:

        1) Device SCSI bus interface chips;

        2) Ground loops.

        The SyQuest, Zip & Jaz drives; and many inexpensive scanners, are
notorious for poor quality SCSI chips in them. This can wreak all sorts of
havoc on a SCSI chain, especially if the hard drive is on the same bus as
these troublesome devices.

        This leads directly to the NT "change of heart" to use ATAPI (IDE) CD-ROM
players instead of SCSI CD-ROM's, so that they would not interfere with
(i.e. slow down) the main disk drive access.

        The best advice I have for people that have a lot of devices is to "divide
and conquer" putting the slow devices on one "slop" bus and the hard
drive(s) on their own private bus. This was a problem in the past with
NuBus Macs, when you only had one SCSI bus and a Jackhammer was $800; but
today with Mac PCI cards about $200 for an Atto Express or Adapcrap; and
x86 & Alpha cards about $40, it pays to split the bus into 2 or more SCSI
buses.

        The second issue relates to the "Apple Hack" 25 pin SCSI connector: This
was OK for SCSI-1 speeds (2 mHz bus clock); but as speeds climbed this
connection failed miserably. This is because Apple combined signal returns
together... This is OK for D.C. and low frequencies; but deadly as the (bus
clock) frequency rises.
         
        What is even worse is when you go "back and forth" out on the chain
between devices that have DB-25 and Centronics-50 connectors... This is
just trouble waiting to happen. What I prefer to do, for Apple Hack DB-25
SCSI connectors is use 25 - 25 cables as I go out the chain; then have the
chain "fan out" to 50-50 cables. For SCSI controllers that start out with
50 pin connectors the strategy is to keep the chain at a 50 conductor
"width" then "fan down" to 25 conductor connections.

        Another trouble spot is termination power ("Term Power"). If you have
multiple sources of termination power on a SCSI bus, you'll again get
ground loops as each regulated source tries to "fight" for the right
voltage at that node... And when there are different term power voltages at
different nodes (which there WILL be), then you get a current flow through
the cables. And since the voltage regulators each have their own time
constants, oscillations will occur. And with shared ground lines, all hell
breaks loose.

        Lastly, I highly recommend Granite Digital's SCSI cables, especially their
Teflon ribbon cables. They are not cheap; but for high performance machines
they are priceless.
 <http://www.scsipro.com>

        Cheers!
        Dan Schwartz

At 03:33 AM 2/12/99 -0600, Kelly wrote:
>I don't recall seeing anything that says SCSI devices have to be
>numbered in the same order that they appear in the chain, only that they
>are limited to seven devices (under standard setups and usages) and the
>devices must all have a distinct number (not repeated elsewhere in the
chain).
>
>However, . . .
>
>My own limited experience with SCSI has been that it seems to matter if
>your external devices are numbered in the same sequential order in which
>they lie along the chain.
>
>It seems that I especially had trouble with the 1Gig Iomega Jaz external
>drive until the SCSI numbers matched the position of each device in the
>chain. I believe Apple's drivers are great for SCSI, but Iomega's
>drivers are pretty fickle (the latest MacIo10a driver not being too bad
>though). When having problems, things always went better when the Jaz
>drive was off or disconnected. It works okay now.
>
>I have followed suggested procedure by installing the Epson Scanner as
>the last device on the chain and switching on its' termination. And I
>think the Jaz is the first thing on that set up now (also terminated).
>
>Since ordering the devices and their numbers the same order as their
>order in the chain (but not necessarily the same number as their
>location), I have only had to terminate the first and last device in the
>external chain and have had no more problems.
>
>Prior to this, I had to frequently do disk repairs, trash finder
>preferences, zap pram, etc . . . in order to get things running again
>till the next time.
>
>Until I did this ordering, I had to use multiple terminators along the
>way to get devices to appear/work. Everything was come and go.
>
>Since there is no scientific basis for all that I just said, I suppose
>this is why it is called VooDoo SCSI.
>
>And BTW, that goat thing was funnnnnnnny!
>
>Thanks Dan.
>
>GODBlessUsAll.
>
>Pat Kelly McCarthy
>
>
>
>>
>> Subject:
>> Re: [WinMac] SCSI Voodoo
>> Date:
>> Thu, 11 Feb 1999 11:42:28 -0700
>> From:
>> Bruce Johnson <johnson@Pharmacy.Arizona.EDU>
>>
>>
>>
>> HA!! Having spent all weekend doing the SCSI voodoo dance, adding an
>> external CD-R to my Mac, losing a disk partition, then eventually, the
>> whole disk in the process, all I can say is D***! I forgot the $@%#@!#!
>> goat! I KNEW a chicken wasn't big enough!
>>
>> ...and they lie...I didn't get my chain (internal CD, 2 HDD, external
>> Syquest and CDR) working until 4 of the 5 devices were terminated...but
>> it may have certainly been that goat issue.
>>
>

 -----------------------------------------------------------------

        <mailto:expresso@snip.net, Dan@Hemnet.com>
         
        ALTERNATE: <mailto:expresso@workmail.com>

                Webmaster for <http://www.faulknerstudios.com>

        **Your Corel Solution Partner**

                **Your UltraBac Solution Source**

 -----------------------------------------------------------------

* Windows-MacOS Cooperation List *
* FAQ: <http://www.darryl.com/winmacfaq/> *
* Archives: <http://www.darryl.com/winmac/> *
* Subscribe: <mailto:winmac-on@xerxes.frit.utexas.edu> *
* Subscribe Digest: <mailto:winmac-digest@xerxes.frit.utexas.edu> *
* Unsubscribe: <mailto:winmac-off@xerxes.frit.utexas.edu> *



This archive was generated by hypermail 2.0b2 on Fri Feb 12 1999 - 08:50:23 PST