Target uses the following condition;
Put DistT =
((sequence id specified in ORB)-(expecting sequence id)) mod (2^m)
IF ((DistT) >= (2^(m-1)) THEN initiator is behind
ELSE IF (0<DistT<(2^(m-1)) THEN initiator is ahead
ELSE initiator is synchronized
Following figure shows the relationship between each sequence id.
"Initiator" (last completed) (going to append)
v(S1) v(S2)
| |
"Target" (expecting) (specified in ORB)
v(S3) v(S4)
| |
|<--------da------->|
| | |
"Target(ahead)" (specified in ORB)
v(S4)
->| |<- db
S1-S4 represents the sequence IDs.
By the initiator's condition, (S2-S1) mod (2^m) < (2^(m-1)).
Because the initiator is recognizing that S1 is completed,
0 < (S3-S1) mod (2^m) < (2^(m-1)).
Thus, the distance "da" in above figure, (S2-S3) mod (2^m) < 2^(m-1).
So, target recognizes S2 as ahead.
If the initiator is behind, S4 will be between S1 and S3 as show
above "Target(ahead)".
Because (S3-S4) mod (2^m) < (2^(m-1)), the distance "db" in above
figure, (S4-S3) mod (2^m) >= (2^(m-1)).
So, target recognizes S4 as behind.
I think this method makes target free from reporting "ABORTED" status
and makes initiator free from taking recovery actions due to the
identifier gap.
Akihiro Shimura
On Tue, 28 Jul 1998 07:49:16 +0900 (JST)
Akihiro Shimura <shimura@pure.cpdc.canon.co.jp> wrote:
> 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.
>
-- Akihiro Shimura (shimura@pure.cpdc.canon.co.jp) Office Imaging System Promotion Project CANON INC.