Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!evax!utacfd!merch!cpe!adaptex!adaptx1!neese
From: neese@adaptx1.UUCP
Newsgroups: comp.periphs.scsi
Subject: Re: <13400@unixland.uucp>
Message-ID: <283400058@adaptx1>
Date: 1 Mar 91 19:27:20 GMT
References: <1942@public.BTR.COM>
Lines: 66
Nf-ID: #R:public.BTR.COM:1942:adaptx1:283400058:000:3547
Nf-From: adaptx1.UUCP!neese    Feb 28 09:34:00 1991


>/* ---------- "Re: <13400@unixland.uucp>" ---------- */
>In article <283400055@adaptx1> neese@adaptx1.UUCP writes:
>>The length of the cable (i.e. SCSI bus) does affect the data transfer rate.
>>Although the effect is minimul.  For every foot of cable you cause a slew
>>in the SCSI bus timing of 2ns.  So with a little math:
>>
>>If you have a 6 foot cable (includes the internal and external), and are
>>transferring a block's worth of data (UNIX) you would incur approximately
>>(6 * 2 * 1024) 12.288 micro-seconds of delay in the overall transfer for each
>>and every transfer.
>>And of course, the longer the cable and the bigger the transfer the longer the
>>overall delay gets.  This example does not take into account the selection,
>>command, and status phases that occur for each transfer as well.
>
>Uh, Roy, I beg to differ with your conclusions in this regards.
>
>The delay, using your example, "should "be a CONSTANT 12nS upon the initiation
>of data transfer, not an additive delay with each new byte (unless my
>understanding of SCSI is really skewed, for which I'd appreciate clarification)
>
>Given my (original) example 20 foot cable, I'd be seeing some 40 microSeconds
>of delay on my system by your calculation and THAT'd be definitely noticeable
>as it's my boot (aka "system") disk (a Quantum 80S) that's at the far end!  :-)
>
>It is (was? :-) my understanding that once a transfer starts, all requested
>bytes are placed on the bus and thus no additional delays would be seen after
>the (in my case (20')) initial 40nS delay.
>
>I (and, I'm sure, others) would appreciate your comments (and, if I'm wrong,
>don't hesitate to flame! :-)

No flame required.  It's good to be challenged from time to time.  Keeps things
honest.
With the question asked I went back to my handy dandy spec and verified the
information I supplied.  The skew is only part of the overall picture.  In
reality all signal pulse widths are lengthened up to 2ns/foot of SCSI bus.
So the net effect is acutally worse than I described, as I did not take into
account the various phases and only supplied changes based on the data
transfer only.  I also left out a very important figure.  I only described
what would happen on the TRUE signals, forgetting that the FALSE signals
would also be stretched.  The signal doesn't actually get stretched.  The
2ns is the time it takes a signal to go 1 foot and as the SCSI bus targets
and initiators react to these signals, they would take longer due to the signal
taking longer to reach it's destination.  So to modify the equation:

((Bus_length * 2ns * data_length) * 2)

Also a note about cables.  External cables come in many varieties.  The
best use twisted pairs in the cable.  This is the best for noise immunity,
but this also adds a substantial amount of length to the SCSI bus.  Depending
on how tight the twisted pair is, the lenght of the SCSI bus could be up
to 50% longer than the actual length of the cable.  So your 6 foot cable
could acutally add 9 feet to the SCSI bus.  The only way to know how the
cable is constructed (short of cutting it open) is to ask the manufacturer
of the cable.  Myself, I like to use flat cable for the external and build
my own.  Garantees impedence matching between the internal and external
cables.  The FCC may not like it, but the flat ribbon cable is a good cable
as you are garanteed all lines are the same length with alternate signal
ground matching.

Hope this helps.

			Roy Neese
			Adaptec Senior SCSI Applications Engineer
			UUCP @  neese@adaptex