neese@adaptx1.UUCP (02/27/91)
>/* ---------- "speed difference on external drives" ---------- */ > >Does having a SCSI drive external to a 386 system, on a cable >several feet long, affect the data transfer rate? Is it significantly >better to have the drive mounted internally in the system? 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. Roy Neese Adaptec Senior SCSI Applications Engineer UUCP @ neese@adaptex uunet!cs.utexas.edu!utacfd! {nominil,merch,cpe}!adaptex!neese uunet!mlite!adaptex!neese
thad@public.BTR.COM (Thaddeus P. Floryan) (02/27/91)
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! :-) Thad Floryan [ thad@btr.com (OR) {decwrl, mips, fernwood}!btr!thad ]
jerry@gumby.Altos.COM (Jerry Gardner) (03/01/91)
In article <1942@public.BTR.COM> thad@public.BTR.COM (Thaddeus P. Floryan) writes: >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) >I (and, I'm sure, others) would appreciate your comments (and, if I'm wrong, >don't hesitate to flame! :-) Roy is correct. To transfer a byte over the SCSI bus requires the target to assert REQ, after which the initiator (the controller) is free to put a byte on the bus or remove a byte. The initiator will then assert ACK, telling the target (the drive) that it has read/written the data. When the initiator removes ACK, the target is again free to assert REQ again to transfer the next byte. Using a long cable introduces delays in the REQ/ACK handshake. It takes longer for the initiator to see a REQ on the bus and to respond to it, and it takes longer for the target to see the negation of the ACK and to respond to it. Thus, long cables introduce delays for every byte transferred, not just one delay at the beginning of the transfer. -- Jerry Gardner, NJ6A Altos Computer Systems UUCP: {sun|pyramid|sco|amdahl|uunet}!altos!jerry 2641 Orchard Parkway Internet: jerry@altos.com San Jose, CA 95134 Help stamp out vi in our lifetime. (408) 432-6200
neese@adaptx1.UUCP (03/02/91)
>/* ---------- "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
adams@ucunix.san.uc.edu (James Warner Adams) (03/04/91)
In article <283400058@adaptx1> neese@adaptx1.UUCP writes: > >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. Shielded ribbon cable is available. I have also found that simply wrapping the cable spirally with a strip of aluminum foil and grounding the foil at one end eliminates interference. This may affect the impedance, though. I have never used this for anything faster than an external floppy drive, so I don't know how it would affect a faster device. The convenience of ribbons with clamp-on connectors makes it possible for anyone to fabricate a cable at minimum cost and effort. -- Jim Adams Department of Physiology and Biophysics adams@ucunix.san.uc.edu University of Cincinnati College of Medicine <<This space for rent>> The watched tape never streams..............
neese@adaptx1.UUCP (03/05/91)
>/* ---------- "Re: <13400@unixland.uucp>" ---------- */ >In article <283400058@adaptx1> neese@adaptx1.UUCP writes: >> >>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. > >Shielded ribbon cable is available. I have also found that simply >wrapping the cable spirally with a strip of aluminum foil and grounding >the foil at one end eliminates interference. This may affect the >impedance, though. I have never used this for anything faster than an >external floppy drive, so I don't know how it would affect a faster >device. The convenience of ribbons with clamp-on connectors makes it >possible for anyone to fabricate a cable at minimum cost and effort. The problem with shielded cable is the possible induction of noise from the ground source into the SCSI bus. Roy Neese Adaptec Senior SCSI Applications Engineer UUCP @ neese@adaptex