tape_command_order (forward)

John Lohmeyer - SCSI jlohmeye at Symbios.COM
Thu Jul 25 16:30:44 PDT 1996


* From the SCSI Reflector, posted by:
* John Lohmeyer - SCSI <jlohmeye>
*
This is another message that majordomo 'decided' was an administrative
request and did not post to the SCSI Reflector.  I'm not sure why...

John

> >From scsi-owner  Thu Jul 11 17:05:33 1996
> Received: from mpdgw2.symbios.com ([204.131.201.2]) by Symbios.COM (8.6.8.1/8.6.6) with ESMTP id RAA09895 for <scsi at symbios.com>; Thu, 11 Jul 1996 17:05:32 -0600
> Received: (from root at localhost) by mpdgw2.symbios.com (8.6.8.1/8.6.6) id RAA29647 for <scsi at symbios.com>; Thu, 11 Jul 1996 17:05:33 -0600
> Received: from hustle.rahul.net(192.160.13.2) by mpdgw2.symbios.com via smap (V1.3)
> 	id sma029594; Thu Jul 11 17:05:13 1996
> Received: from endl.UUCP by hustle.rahul.net with UUCP id AA25353
>   (5.67b8/IDA-1.5 for scsi at symbios.com); Thu, 11 Jul 1996 16:05:11 -0700
> Received:  by endl.us.com (UUPC/extended 1.12b);
>            Thu, 11 Jul 1996 16:05:49 pdt
> Message-Id: <31e588cd.endl at endl.us.com>
> Date:      Thu, 11 Jul 1996 16:05:49 pdt
> From: "Dal Allan" <dal_allan at mcimail.com>
> Organization: ENDL Inc (14426 Black Walnut Ct, Saratoga, CA 95070)
> To: scsi at symbios.com
> Subject:   tape_command_order
> 
> A few observations about interfaces in general which may or may not help the 
> discussions, followed by a specific recommendation. 
> 
> 
> The IBM Block Multiplexer Channel was the original common interface for 
> multiple device types. It was fully interlocked and offered three sets of 
> information:
>      Channel End  on the physical interface = Data received successfuly 
>      Device End   on the physical interface = Command Completed Status
>      Sense Data   at the command interface 
> 
> 
> Along came IPI which was not an interlocked interface (although the IPI-PH 
> parallel defintion was) and was heavily influenced by the programmers who 
> used BMC and it provided: 
>      Successful Information Transfer          on the physical interface 
>      Command Completion Response w/Status     at the command interface 
> 
> Command Completion Responses which only contained Successful Status could be 
> suppressed with equivalent of Mode Select i.e. success was implicit unless 
> otherwise reported. 
> 
> 
> Along came SCSI which was heavily influenced by the hardware design of the 
> BMC and it provided. 
>      Command Complete Status                 on the physical interface
>      Request Sense Data                      at the command interface
> 
> 
> Along came serial variations which are not interlocked and introduced 
> Autosense (a la IPI). 
> 
>      Class 1/Class 2 Fibre Channel offer Successful Transfer w/ACK *
>      Command Completion Response w/Status at the command interface 
> 
> * WARNING: Many assumptions about what ACK does are not correct.
> 
> ACK does NOT mean some processing entity has seen the frame and agreed it is 
> the 'right' kind of frame. ACK means the port received an error-free frame 
> e.g. blind ACKing as done by Tachyon. I know that FC-PH implies 'more' with 
> things like the History bit but.....(that is one of the things I hope we can 
> address in the next generation of documentation). 
> 
> If you think of ACK as a hardware assist to Fibre Channel to handle end-to-
> end buffer management you are more right than wrong. 
> 
> The anxiety about Class 3 vs Class 2 should dissipate. I am a Class 2 fan 
> and there are good reasons for Class 2, but they are of no relevance to any 
> discussion on command delivery. 
> 
> 
> Can we agree about the heart of the concerns on tape?
> 
>    Every command has to arrive in the order it was transmitted and if any do
>    not arrive then that shall be detectable by the recipient. 
> 
> Or is it really?
> 
>    Every command has to be processed in the order it was transmitted and if 
>    any do not arrive then that shall be detectable by the recipient. 
> 
> Assuming it is either one of the above, I prefer the second.
> 
> 
> We spoke in generalities about adding 'something' at the last Fibre Channel 
> working group based on a proposal by Ed Gardner. Here is something specific.
> 
> IPI had a thing called CRN (Command Reference Number) which was part of the 
> command packet. It was the equivalent of the Queue Tag to identify back to 
> the host which command was being serviced. CRNs could be used to track the 
> order of command transmittal. 
> 
> There is no room for a CRN in the CDB but we do have an FCP_CMND IU.
> 
>  - What if a CRN were added to FCP_CMND? 
> 
> It would be incumbent upon the initiator to maintain a separate incrementing 
> counter by LUN and it would be incumbent upon the target to execute commands 
> in CRN order rather than arrival order. 
> 
> NOTE: You could keep count by Sequence instead of command but the target can 
> tell by context what should be happening once a command has begun execution. 
> As this is a command-related concern, stick with a solution on commands. 
> 
> 
> See you all next week. I will not be on the call tomorrow, which is why this 
> is going out now. It may add something new to the conversations. 
> 
> All the best,
> 
> Dal
> 
> Footnote: To those of you who have never heard of IPI, it antedates SCSI and 
> was overrun by SCSI. A large number of the problems being encountered now 
> were resolved in IPI during its development cycle back in the 1970's and 
> early 1980's. IPI-3 is kind of a combination SAM/SPC/SBC document and serial 
> physical interfaces were an assumed environment. It was layered from Day 1 
> and IPI-2 defined device-level commands. There was an IPI-PH that ran full 
> duplex 8-bit for control and half-duplex 16-bit for data which has been 
> relegated to the dustbin of history. IPI-3 lives on over HIPPI-PH now (HIPPI 
> users extended IPI-3 from a Master-Slave to a Peer-Peer interface). 
> 
> 
> 
>                                Other Snippets
> 
> This is more of a bitch than anything else at language and statements which 
> I feel are not apropos to the discussion. Glad to have you aboard Glenn, but 
> let's get facts and details instead of hysteria and diatribe. 
> 
> >                                                       VMS is not
> > used to Russian roulette games with user data...we leave that to
> > other OSs. 
> 
> No OS is designed to play Russian roulette. 
> 
> >                  We do need to get a SCSI status, and we need to get it
> > reflecting a particular I/O. Otherwise we need to sit and wait, and
> > run class 3 REAL slowly. 
> 
> You may have dependencies in your code but they have nothing to do with 
> Class 3. Class 2 ACK does jack for you, it is not a status. 
> 
> >                        I'm told that fabric delays of 10 or more
> > seconds will be common. If that's anywhere near right... 
> 
> I have never heard anyone make such a statement. If you want real data, call 
> the guys at Brocade. Tell them your fabric topology and get a real estimate. 
> 
> 
> 
> To comment on an assumption that Erich made:
> 
> > The sequential nature of tape data requires preservation of command order,
> > something not guaranteed by the present queueing model.  
> 
> I would see nothing wrong in SSC describing the tape model as being reliant 
> upon command order and specifying that executing commands in order is a 
> requirement to be SSC-compliant. Now as to what 'in order' means......
> 
> 
> 




More information about the T10 mailing list