Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!pacbell.com!tandem!zorch!vsi1!altos!gumby!jerry From: jerry@gumby.Altos.COM (Jerry Gardner) Newsgroups: comp.periphs.scsi Subject: Re: <13400@unixland.uucp> Message-ID: <4705@gumby.Altos.COM> Date: 28 Feb 91 18:25:09 GMT References: <13400@unixland.uucp> <283400055@adaptx1> <1942@public.BTR.COM> Reply-To: jerry@altos.COM (Jerry Gardner) Organization: Altos Computer Systems, San Jose, CA Lines: 31 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