[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference ssag::ask_ssag

Title:Ask the Storage Architecture Group
Notice:Check out our web page at http://www-starch.shr.dec.com
Moderator:SSAG::TERZAN
Created:Wed Oct 15 1986
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:6756
Total number of notes:25276

6468.0. "Help about Synchronous transfer in SCSI" by ULYSSE::VALENTIN () Tue Mar 11 1997 09:51

Hi all,

    I have an understanding problem from SYNCHRONOUS TRANFER in DATA PHASE.

    Let consider a scenario where a host computer (initiator) sends data to 
    an array (target). I can follow the main stream of the story till this
    moment when the target put out in advance a number #n of REQ signal.
    Then, the initiator put one ACK to answer the REQ and then it bursts
    out data on the DB lines synchronously until the number of REQ/ACK is
    equal.

    My 1st question is :
    Is the number #n of REQ-in-advance limited ?
    
    2nd question :     
    "If the initial request is a DISKCOPY like command, it could take at
    least  3'20'' (the best theory case) to transfer 2 Gigabytes of data
    using a Narrow Fast SCSI bus. I assume this initial request will use a
    10-byte command block descriptor. I've searched the spec., but nowhere
    is specified the  algorythm that tells the target/initiator to free up
    the bus time to time". 

    I can't imagine that a target could lock the bus during all this time.
    Maybe this part of the agreement between initiator and target is left
    up to the vendor imagination during the design of controlers and
    adapters ...

    So does somebody know about this algorythm ? or some good pointer that
    explain this type of problem.
    Thanks,
Philippe.
T.RTitleUserPersonal
Name		DateLines
6468.1let me try, in brief terms...SUBSYS::VIDIOT::PATENAUDEAsk your boss for ARRAY's...Tue Mar 11 1997 11:1135
>    My 1st question is :
>    Is the number #n of REQ-in-advance limited ?

The number you refer to is called the "offset". Offsets are device specific
values (RZ28M and RZ28B are 8). The initiator gets this value from the device as
part of the data returned during a Syncronous Data Transfer Request (SDTR).

>    2nd question :     
>    "If the initial request is a DISKCOPY like command, it could take at
>    least  3'20'' (the best theory case) to transfer 2 Gigabytes of data
>    using a Narrow Fast SCSI bus. I assume this initial request will use a
>    10-byte command block descriptor. I've searched the spec., but nowhere
>    is specified the  algorythm that tells the target/initiator to free up
>    the bus time to time".

The amount of time a device will stay on the bus is also set in the device. What
happens is the device will force disconnect then rearbitrate and reconnect to
accept/return more data. Thus giving other devices a chance at the bus. 

>    I can't imagine that a target could lock the bus during all this time.
>    Maybe this part of the agreement between initiator and target is left

Actually although it does not happen much because of forced disconnects, a drive
at the highest priority ID (7) could "hog" the bus by not allowing others to
arbitrated during the disconnect/reconnect time. This usually results in command
timeouts or bus transmission faults. That is why controllers are at 7 normally,
so they can break in.

roger

    up to the vendor imagination during the design of controlers and
    adapters ...
6468.2SMURF::KNIGHTFred KnightThu Mar 13 1997 14:0216
>    My 1st question is :
>    Is the number #n of REQ-in-advance limited ?

This value is negotiated between the host and the device.
Whoevers value is the minimum is the one that is used.

The PMAZB/C adapters for the Bird machines for example have a
maximum of 15.  But if you connect a RZ28M (with a maximum of
8), then you will end up using 8.  If you have a device with a
maximum 15 and you hook it to a KZPAA (which has a maximum of
8) then again, you'll use 8.

So both the device and the host are involved in setting this
number.

	Fred