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