Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!uunet!orca!tonto!courtney From: courtney@tonto.es.com (Courtney Goeltzenleuchter) Newsgroups: comp.periphs.scsi Subject: Re: sync scsi tape drives (non 1/2 inch) Message-ID: <1991Feb14.181424.2010@dsd.es.com> Date: 14 Feb 91 18:14:24 GMT References: Sender: usenet@dsd.es.com Reply-To: courtney@tonto.es.com (Courtney Goeltzenleuchter) Organization: Evans & Sutherland Computer Corp., Salt Lake City, UT Lines: 41 Nntp-Posting-Host: 130.187.85.156 In article , grl@brb.dmt.csiro.au (Greg Lehmann) writes: > Does anybody have a DAT or 8mm tape drive that can do synchronous scsi > transfers. Apparently most 1/2 inch tape drives support it these days. > I am interested in the brand names of such beasts and in the performance > compared to non-sync operation. What sort of throughput increase do > you get when you start running synchronously? Also is there any > improvement with the dreadfully long pauses that occur when you do things > like mt -f /dev/rst1 rew or other operations that just cause slowdowns > like tar cf /dev/rst1 ~mike ? I don't know of any tape drives (DAT, 8mm or 1/2 inch) that support synchronous SCSI but I can say that it's unlikely it will make any difference. Data transfers are the only operations that are affected with synchronous. This could help the overall system throughput because the device is locking up the SCSI bus for shorter periods of time, but since most tape drives are quite slow (< 500kbs) speeding up the transfers isn't going to make much difference. For operations like rewind and forward space and the like, synchronous isn't going to make any difference. These operations are dependent upon the speed of the motor and/or the data transfer rate internal to the drive since very little data goes across the SCSI bus. > > Finally I still haven't heard a description of synchronous scsi and how it > differs from ordinary scsi that satisfies me. Any pointers? SCSI requires that every byte that goes across the bus be acknowledged by the receiver. In asynchronous mode that means the next data byte isn't sent until the ACK is received. In synchronous mode the sender is allowed to run ahead of the receiver ( a fixed number of bytes) allowing it to not wait for the ACK. The sender can continue transmitting bytes so long as the number of outstanding ACKs remains below a fixed size (usually 8-15). So the speed increase comes because we don't have to wait after each byte for the acknowledge before sending the next byte. -- Courtney Goeltzenleuchter, Evans & Sutherland Computer Corporation Design Systems Division, P.O. Box 8070, Salt Lake City, Utah 84108 (801) 582-5847 UUCP: { decwrl | utah-cs | sun!sunpeaks!sunslc } !esunix!cgoeltze INET: courtney.dsd.es.com