One problem with this requirement is that it was assumed
that the particular SBP-2 implementation to be used
would not have any information about 1284.4 - specific
requirements for FIFO processing of outbound/inbound
ORBs. Unless the SBP-2 layer software interface allows
this type of option to be specified for a particular login.
This may not be a problem for a target if the target-side
1284.4 implementation provides its own SBP-2 fetch
agent. I am not familiar with how SBP-2 implementations
are being designed; whether they implement "internal"
fetch agents, or do they support "external" fetch agents
for clients with special ORB processing requirements?
Randy
> -----Original Message-----
> From: Fumio Nagasaka [SMTP:fumiona@venus.dtinet.or.jp]
> Sent: Sunday, December 07, 1997 12:35 AM
> To: '1394-architecture@1394ta.org'; 'p1394@pwg.org'
> Cc: 'PJohansson'
> Subject: P1394> Re: SBP-2 Bidirectional ORB
>
> Through the 1394 PWG discussion, I *was* thinking "in order execution"
> for
> linked list of ORBs is required for printing application. Now I think
> the target
> may skip ORB execution in some case, even in a printing application,
> utilizing
> multiple logical channel.
>
> PJohansson@aol.com writes:
> * Well, how does the initiator *know* that the target has no data? Use
> a
> * timeout? No, I think that this would be an ill-advised
> strategy---very
> * inefficient, too.
>
> I don't think the initiator knows the target has no data. And I do not
> think
> the application layer in the target device know the transport layer
> received
> IN-ORB request from the initiator. Thus if there is an input request
> between
> other ORBs and the target does not have any data to reply, SBP-2
> transport
> layer would not decide whether the application is going to send data
> just
> 10 msec later or after 10 minutes hard working.
>
> We at 1394 PWG found the higher layer in the protocol stack in the
> target
> shall service multiple logical channels. Then, the target agent may
> fetch
> ORBs and distribute them into each logical channel. Please see an
> attached
> figure:
>
>
> Each logical channel shall consume ORBs in the queue. Even if a
> logical
> channel received an ORB which is not executable, other logical
> channels
> would be available.
>
> Actually when paper out, the printer does not print and it does not
> consume
> PCL commands. Then any ORB which is pointing print data will be
> stalled.
> However the initiator may send status request through an available
> logical
> channel. The initiator can get reason why the ORB is stalled. And if
> the
> trouble is unrecoverable, then it may send *TASK_ABORT* to the target.
>
> The PWG printer profile for SBP-2 is defining logical channel field in
> command
> block of the "Normal command block ORB" data structure.
> --------------------------------------------
> -------------------------------
> Fumio Nagasaka
> Epson Software Development Laboratory Inc.
> Tel +81 268 25 4111, Fax +81 268 25 4627
> E-mail to nagasaka.fumio@exc.epson.co.jp
>
> -----Original Message-----
> From: PJohansson [SMTP:PJohansson@aol.com]
> Sent: Thursday, December 04, 1997 11:17 AM
> To: fumiona@venus.dtinet.or.jp; 1394-architecture@1394ta.org
> Subject: Re: P1394> Re: SBP-2 Bidirectional ORB
>
> In a message dated 97-11-21 12:18:06 EST, fumiona@venus.dtinet.or.jp
> writes:
>
> <<If the target device does not have any data to reply, when the
> initiator is
> keeping Out-ORB, In-ORB and Out-ORB, the target fetch agent will be
> stalled at
> second ORB and third ORB will not be consumed.>>
>
> This is a true statement ONLY if the target reports in-order execution
> in its
> configuration ROM. To keep things in perspective, all of the
> discussions of
> printers (of which I am aware) have assumed in-order execution.
>
> <<In this case, "AGENT_STATE" shall be ACTIVE at this moment. Thus if
> the
> initiator try to ping DOORBELL, this write-transaction for DOORBELL is
> redundant. To overcome this state, the initiator need to write a value
> to
> AGENT_RESET register to force "AGENT_STATE" to turn RESET state. Is
> this a
> normal job for this purpose?>>
>
> Well, how does the initiator *know* that the target has no data? Use a
> timeout? No, I think that this would be an ill-advised strategy---very
> inefficient, too.
>
> Better for the target to complete the second ORB in the example above
> and
> indicate zero data transfer. It's then free to go on the the third
> ORB.
>
> Peter Johansson
>
> Congruent Software, Inc.
> 3998 Whittle Avenue
> Oakland, CA 94602
>
> (510) 531-5472
> (510) 531-2942 FAX
>
> pjohansson@aol.com
> << File: InOrbStalled.PDF >>