dinah@krebs.bcm.tmc.edu (08/02/89)
Here is the summary of the responses I received from the question on the
difference between synchronous and asynchronous SCSI. Thanks for your
help. Sorry for the slow response on my part - I changed jobs between the time
I posted and now.
>From sun!aeras!tneale Thu Jul 13 15:34:25 1989
The trade off is speed. Sync runs faster under almost all conditions.
Sync timing is accomplished by a negotiated (drive to controller and vise
versa) set of timing parameters, async works on handshake lines.
The catch is that both your controller (host adapter) and target (disk
drive, etc.) must be synchronous capable - not all drives are.
The SCSI spec says that the minimum data transfer rates are:
async: 1.5 MB/sec
sync: 4.0 MB/sec
Obviously, higher data rates can mean high performance for your system.
There are other disk drive specs that will have a larger impact on your
system.
========================================================================
From: kong!ncratl.Atlanta.NCR.COM!mclauss
The SCSI interface has several modes. There are modes for
arbitration, selection, bus idle, data in, data out, command in, command out
and several others. The asynchronous SCSI bus puts out a request (REQ) signal
along with a data byte and waits for an acknowledge (ACK) signal before
sending out the next byte with the next REQ.
This means that the cable must be traversed 2 times for each byte. That makes
the transfer time vary with cable length. The longer the cable the slower
the data transfer.
For synchronous SCSI, the initiator and target device do some negotiation
up front and set up some hardware parameters. Once this is done, anytime
data is transfered (see below), a REQ and data are sent, then after a
parameter delay another REQ and data are sent. This is done for a
parameterized number of times up to (I believe) 10. The ACK pulses for
each REQ may begin whenever they get there and are expected at certain
time intervals after that. The ACK pulses are counted to make sure the
correct number are recieved. The following phases transfer data:
data in
data out
command in
command out
Synchronous makes SCSI less sensitive to cable length and provides fast
data transfer. The problem with that is that the data transfer time
is sometimes insignificant when compared to the total overhead to take
care of other things. SCSI 2 addresses some of these problems to
reduce the other overhead so that increasing the data transfer speed
will actually make a big difference in the total speed of data.
Until that time, going to synchronous SCSI may only increase total
throughput by about 25% to 50%. Think hard before you pay a lot
of extra money for a synchronous drive. Also keep in mind that a
synchronous drive will be asynchronous unless the host is synchronous
also.
Hope this helps
============================================================================
From rutgers!ssd.harris.com!garyb@gazette.bcm.tmc.edu Wed Jul 19 16:01:55 1989
===> Turn on technical SCSI mode
Asynchronous SCSI uses a REQ/ACK handshake for every byte that is
transferred. So in the case of an input request, the target drives
the data bus to it's correct value, waits a standard delay, and then
drives REQ to true. The initiator then reads the data bus when it
sees REQ transition to true. After having read the data bus, the
initiator drives ACK to true, which tells the target we received the
data, and it may continue. Synchronous SCSI uses a similar handshake
with the exception that the transferer need not wait for receipt of
an ACK before setting up another data item. Instead, the data values
are held for some known delay, and then the next value is setup.
Asynchronous transfers are the default, and in order to use sync
transfers, the targets and initiators capable of synchronous transfers
(this is an optional feature after all) negotiate for synchronous
transfers via send a SYNCHRONOUS DATA TRANSFER REQUEST message. Using
this message, target and initiator negotiate the parameters of the
synchronous transfers. Rejection of the message by either target or
initiator will mean that async transfers must be used. FYI, this
description is taken largely from the SCSI spec, ANSI X3.131-1986.
===> Turn off technical SCSI mode
Anyway, what this all means is that devices which support SCSI
synchronous transfers have a higher theoretical data transfer rate.
When you plug in all the appropriate delays, the maximum transfer rate
for async SCSI transfers works out to around 1.5 Mbytes/sec. In a
similar fashion, the maximum xfer rate of synchronous SCSI can be
calculated to ~4 Mbytes/sec. So for SCSI busses where data phases
dominate (ie: lots of large transfers), using synchronous transfers
can be a big win, especially if there are multiple targets, and bus
bandwidth is at a premium. However, be forewarned that many
peripherals that come with embedded SCSI controllers do not support a
data transfer rate greater than that of the theoretical async limit.
In these cases, synchronous SCSI buys you nothing because the device
cannot sustain a transfer rate fast enough to take advantage of the
higher maximiums. As an example there are several disk drives that we
use here that support sync SCSI transfers. Listed below are the avg
and peak transfer rates. As you can see, only the last one has avg
transfer rates significantly above the 1.5 Mb/s async limit, and it
just noe beginning to ship in production quantities.
Disk Drive Avg Peak(sync) Peak(async)
===============================================================
FUJI MX2246SA 171 Mbyte 1.25 Mb/s 2.5 Mb/s 1.5 Mb/s
FUJI MX2249SA 389 Mbyte 1.25 Mb/s 2.5 Mb/s 1.5 Mb/s
FUJI MX2250SA 760 Mbyte 3 Mb/s 4 Mb/s 1.5 Mb/s
So unless SCSI bus bandwidth is at a preminim in your configuration,
and you have some pretty fast peripherals, chances are you don't
really need synchronous SCSI. I guess it would still be advantageous
to have, but it would not be strictly necessary.
=========================================================================
Thanks again
Dinah Anderson internet: dinah@bcm.tmc.edu
Baylor College of Medicine uucp: {rutgers,mailrus}!bcm!dinahjlohmeye@entec.Wichita.NCR.COM (John Lohmeyer) (08/03/89)
In article <1637@gazette.bcm.tmc.edu> dinah@krebs.bcm.tmc.edu () writes: >Here is the summary of the responses I received from the question on the >difference between synchronous and asynchronous SCSI. Thanks for your >help. Sorry for the slow response on my part - I changed jobs between the time >I posted and now. > When I saw your original posting, I was too busy to respond. I'm glad you posted this summary. In order to not waste too much bandwidth, I've deleted a lot of excellent responses. However, there are a couple nits I'd like to pick (no flame intended :-) >From sun!aeras!tneale Thu Jul 13 15:34:25 1989 > >The SCSI spec says that the minimum data transfer rates are: ^^^^^^^^^^^^^^ > > async: 1.5 MB/sec > sync: 4.0 MB/sec > Actually... The SCSI standard does not really specify these numbers. They are widely quoted, however and you could derive the 4.0 MB/sec number from the other times specified in SCSI. The async number is highly dependent on both the implementation of the SCSI devices and the cable length. On the long cables permitted by the differential driver option even an excellent implementation will not achieve much over 1 MB/sec. On very short cables (within a cabinet) some implementations can go faster than sync SCSI. Many sync SCSI implementations can achieve up to 5 MB/sec. I once gave a presentation at a SCSI Forum on why all these different numbers get quoted. I can't give it all here, but I thought it might be helpful to explain the difference between the 4 MB/sec and 5 MB/sec numbers that we frequently see for the maximum sync speed. The 4 MB/sec figure assumes that the drivers and receivers in the sending device are external from the protocol chip and hence are subject to skew delays. That is, the protocol chip must allow time for differences in the propagation speed of the drivers. If the drivers are built into the protocol chip, then there will be almost no difference in their propagation speeds. Thus such a design can negotiate for a little faster speed: 5 MB/sec. This is only practical for single-ended designs -- no protocol chips build in the differential drivers due to the heat these things dissipate. >From: kong!ncratl.Atlanta.NCR.COM!mclauss > ...stuff deleted... > >This means that the cable must be traversed 2 times for each byte. That makes >the transfer time vary with cable length. The longer the cable the slower >the data transfer. > >For synchronous SCSI, the initiator and target device do some negotiation >up front and set up some hardware parameters. Once this is done, anytime >data is transfered (see below), a REQ and data are sent, then after a >parameter delay another REQ and data are sent. This is done for a >parameterized number of times up to (I believe) 10. The ACK pulses for >each REQ may begin whenever they get there and are expected at certain >time intervals after that. The ACK pulses are counted to make sure the >correct number are recieved. The following phases transfer data: > > data in > data out > command in [no such phase -- he probably means status phase] > command out [this phase is async only] Actually... There are 2 _round_trip_ delays involved for each byte transferred asynchronously. There is only 1 round trip delay involved for each byte transferred synchronously. But the real speed advantage comes from allowing the handshakes for synchronous transfers to overlap. That is, the sender can keep sending bytes without any acknowledgment up to the REQ/ACK Offset. The REQ/ACK Offset is a negotiated quantity (0 to 255) that is part of the synchronous negotiation (the other part is the Transfer Period). 0 and 255 are special cases. 0 means asynchonous. 255 means there is no maximum REQ/ACK Offset. For most protocol chips, the maximum supported REQ/ACK Offset is roughly how deep their FIFO stack is. Typical values range from 4 to 16. There is no advantage to larger values -- the data won't go any faster. Values above 4 may make it a little easier to interface to these chips, but the maximum cable length of 25 meters means that you can only have about 3-4 bytes "on the cable" at a time. Synchronous ONLY applies to the data phases, DATA IN and DATA OUT. All other phases use asynchronous transfers. Also, the target (controller) always drives the REQ signal; the initiator (host) always drives the ACK signal. For data transfers to the target, the target asserts REQ to request a byte. The initiator puts the byte on the data bus and then asserts ACK to indicate the byte is valid. Thanks for giving me this opportunity to nit pick. :-) -- John Lohmeyer J.Lohmeyer@Wichita.NCR.COM NCR Corp. uunet!ncrlnk!ncrwic!entec!jlohmeye 3718 N. Rock Rd. Voice: 316-636-8703 Wichita, KS 67226 SCSI BBS 316-636-8700 300/1200/2400 24 hours