P1394 Mail Archive: Re: P1394> Recovery (Was Re: Revised PWG1394 Cmd Set)

P1394 Mail Archive: Re: P1394> Recovery (Was Re: Revised PWG1394 Cmd Set)

Re: P1394> Recovery (Was Re: Revised PWG1394 Cmd Set)

Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
Tue, 28 Jul 1998 07:49:16 +0900 (JST)

See comment below,

On Mon, 27 Jul 1998 10:13:31 -0700 (PDT)
Greg Shue <gregs@sdd.hp.com> wrote:

> Akihiro Shimura wrote:
>
> > The initiator is already limiting the number of ORB's not to exceed
> > maximum reorderable number.
>
> (... number of ORBs in the active task set...)
>
> > By making this condition a little severe, I think we can avoid
> > unrecoverable situation without retry interaction between initiator
> > and target.
> >
> > The descriptive condition will be as follows;
> >
> > The initiator limits
> > the number of ORB's not to exceed maximum reorderable number,
> > "AND"
> > to append the ORB that has sequence identifier target can identify
> > as ahead from last completed one.
> > "OR"
> > If there is no outstanding ORB for the queue, the initiator appends
> > ORB that has sequence identifier adjusted to the next number of last
> > completed one.
> >
> > The conditional expression will be as follows;
> >
> > IF ((Number of outstanding ORB for the queue)
> > <= (MAX_TASK_SET_SIZE - n))
>
> (... the first part is always true!)

The initiator is responsible to make the first part true. The
condition represents the way initiator decides to append ORB or not.

> > AND
> > ((((appending sequence id)-(last completed sequence id)) MOD (2^m))
> > < (2^(m-1)))
> > THEN append ORB with (appending sequence id)
> > ELSE
> > IF ((Number of outstanding ORB for the queue) = 0)
> > THEN adjust (appending sequence id) to (last completed sequence
> > id) + 1 and append ORB,
> >
> > where "n" is room for another queue, and "m" is number of bit of
> > sequence id.
>
> Unfortunately, the target isn't going to always recieve
> sequence numbers which are monotonically increasing. This is
> the consequence of an ABORT_TASK applied to the middle of
> a queue. The "sequence number" space has suddenly become
> sparse!

Above condition
> > ((((appending sequence id)-(last completed sequence id)) MOD (2^m))
> > < (2^(m-1)))
prevents the sequence number distance to become "too" apart for the
target to distinguish the initiator is ahead or behind.

> Suddenly a sequence number space >> MAX_TASK_SET_SIZE doesn't
> guarantee that we can detect order in an error recovery
> situation. Both ends may differ as to where they believe the
> "last completed sequence number" is!

The "last completed sequence number" means the number the
"initiator" is recognizing.
Because (a sequence number space >> MAX_TASK_SET_SIZE) does not
guarantee successful detection, additional condition is necessary
to safely append ORB.

The distance between "last completed sequence id(that initiator is
recognizing)" and "appending sequence id(initiator is going to
append ORB with this id)" is always greater than the distance
between "the sequence id target derives from ORB" and "the sequence
id target is expecting to derive".
This makes target detect ahead or behind successfully.

> > If the target finds initiator is ahead, target can simply update
> > recorded identifier with the new value specified by the initiator.
> >
> > Am I missing something?
>
> I think so. Start aborting single tasks from the middle of a
> queue and watch what happens to the "sequence numbers" from the
> target's perspective.

>From this observation, I have made additional condition.

>
> SBP-2 requires the support of ABORT TASK.
>
> --
> Greg Shue
> Hewlett-Packard Company
> All-in-One Division gregs@sdd.hp.com
> ----------------------------------------------------------------
>

--
 Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
 Office Imaging System Promotion Project
 CANON INC.