Subject: RE: P1394> 1284.4 over SBP-2

From: Fumio Nagasaka <[email-masked]>
Date: Mon, 16 Feb 1998 08:41:32 +0900

Hi Greg,

S2 state will not happen, when your model uses "Credit Base Transport".
The initiator will not send more packets than given credits by the target.
--------------------------------------------
-------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to [email-masked]

-----Original Message-----
From:	Greg Shue [SMTP:[email-masked]]
Sent:	Friday, February 13, 1998 3:24 AM
To:	Akihiro Shimura
Cc:	[email-masked]; [email-masked]
Subject:	Re: P1394> 1284.4 over SBP-2

Akihiro Shimura writes:
> Basically, I also support to consider option B, but it is still not
> clear for me how the data transfer of each direction is done
> independently within single login in SBP-2 only solution.
> 
> If target request data transfer by "Data Available" flag in certain
> status block, initiator will subsequently append "SND data-in" ORB in
> the current task list. It will be possible for the target to check if
> there is a "SND data-in" ORB in the task list BEFORE the initiator
> appends the "SND data-in" ORB. After finding there is no "SND data-in"
> ORB, the target may issue another unsolicited status which indicates
> "Data Available". By this status, the initiator may append one more
> (total two) "SND data-in" ORB in the task list. After that, the
> target will need to abort the excessive ORB.
> Is this a way the SBP-2 only solution works?

It's not the way I intended it to work.  Let me work through
the model I've had in mind.

It is a status signal that data is available for the initiator.  It is
not an event requesting a new task be placed on the task list.

The status is updated at exactly two points in time:  on the
completion of a task; and on a spontaneous change from No Data
Available to Data Available when there are to active tasks on the
task list.  It is up to the initiator to determine whether a new
task needs to be enqueued on the task list or not.  The task
enqueuing algorithm for the initiator would basically be:

  for (;;)
  {
      while target has unexpected data available
	  get target data one request at a time

      enqueue one request for an expected data transfer
  }

When the target has data available, and at least one request
exists on the active task list, the data available indication is
given on the completion status of the first ORB.  The initiator
will enqueue a new ORB for receiving target data if, and only if,
no request for target data has already been enqueued on the task
list.  This ORB would be associated with the "hanging read"
already required for independent communication in each direction.

The target would continue to process the ORB list until one of
the following states is reached:

  S1) the ORB list will be empty  (no active task set)

  S2) the ORB list processing stalls at a data transfer to the target,
      and the target has no data for the initiator.
      (no more target buffer space, and no reason to abort the task set)

  S3) the ORB list processing stalls at a data transfer to the initiator
      (initiator expects data from the target, but none is currently
       available)

When data becomes available, the following transitions take place:

  From S1
    the target signals Data Available via unsolicited status;
    the initiator enqueues one ORB to receive the data;
    the target resumes processing the ORB;
    on completion of the request, the target indicates whether
      or not more data is available.

  From S2
    the target aborts all the requests on the task list and indicates
      that data is available for the initiator on each request;
    the initiator enqueues one ORB to receive the data;
    the target resumes processing the ORB;
    on completion of the request, the target indicates whether
      or not more data is available.

    When the target has no more data available, the initiator
      requeues the aborted requests.

  From S3
    the target continues processing the task set

The only ineffeciency occurs when the target doesn't behave the way
the initiator expects.

  If we are doing unidirectional printing, then there is no data
  for the initiator, and the task set is never aborted.

  If we are interacting with the device, and it behaves as expected,
  then there is no unexpected data for the initiator, so the task
  set is never aborted.  (For interactive Postscript, scanning models,
  and request/reply paradigms like SNMP)

  If the target doesn't behave as expected and has lots of unsolicited
  data for the initiator, the target aborts the current task set and
  the initiator pauses sending data to the target until the target has
  no more data for the initiator.

The worst-case scenario occurs if the target keeps generating bursts
of unexpected data for the initiator and the task sets are perpetually
aborted.  The net effect of this is minimized simply by minimizing
the length of the active task set!  Having 2-4 data transfer requests
queued  (e.g. double-buffering) may be sufficient (for most applications)
to keep the task list running and the target busy.

> I think that aborting tasks implies subsequent task retries, and may
> not be efficient.

Yes, aborting tasks implies subsequent task retries.
The overhead is in the target (pre) fetching the ORBs
in order to abort them, and in requeuing the task set
when the data available indication disappears.

But don't forget that the maximum data transfer size is known,
so the target doesn't need to fetch any real data until it knows
that it can complete the request!

> It seems natural to make two independent logins for each direction,
> one for down-link and another for up-link by using the idea to map
> them into logical units. Furthermore, by extending this to allow to
> allocate up-link in reverse fashion (i.e., the target of down-link
> makes a login to the initiator of down-link), the link between two
> devices will become symmetric if both ends have both initiator and
> target functionality.
> 
> Any suggestions?

Haven't we been down this road before?  (Yes, and rejected it.)

> --
>  Akihiro Shimura ([email-masked])
>  Office Imaging Products Development Center 3
>  CANON INC.
> 

-- 
Greg Shue
Hewlett-Packard Company
Office Products Division			[email-masked]
----------------------------------------------------------------

---

From: Greg Shue <[email-masked]>
Date: Tue, 17 Feb 1998 11:47:26 -0800 (PST)

> The initiator will not send more packets than given credits by the target.

Correct.