Subject: Re: Revised BCM selection process

From: "Hattig, Myron" <[email-masked]>
Date: Tue, 4 May 1999 17:00:07 -0700

Kenji and all,

I hope this change was not as shocking to everyone else as it was to me. ;-)
I've looked at the proposal and talked to Peter on the phone about the
proposal and the process by which it changed. Peter agrees the IP/1394 group
should have received a heads-up before BCM election process changed.
Peter may have mentioned it me and I missed his queue. Regardless,
that's water under the bridge so let's move on to technical issues.

I did not see any technical problems with the new proposal. In fact,
I like the new process better. It is certainly simpler to implement. Also
no one owns Intellectual Property associated with it. ;-)  I'll attempt to
address your questions, some of which are the same questions I had.

> >The revised algorithm diverges when the isochronous resource
> manager is not
> >BCM-capable. Whereas the old process employed a
> deterministic back off and
> >resulted in the victory of the BCM candidate with the
> largest physical ID,
> >the new algorithm requires that the BCM candidate set its
> own root hold-off
> >(RHB) bit and initiate a bus reset. This should result in
> the BCM candidate
> >becoming the isochronous resource manager and therefore
> becoming the BCM.
>
> It seems this clause corresponds step f).
>
> : f) If the current isochronous resource manager does not
> implement the
> :    BROADCAST_CHANNEL register, a new isochronous resource
> manager that
> :    is also broadcast channel manager-capable shall be selected.
> :    A candidate broadcast channel manager shall set its own
> force_root
> :    variable TRUE, clear those of all other nodes to FALSE and then
> :    initiate a bus reset. The broadcast channel manager selection
> :    algorithm resumes with a);
>
>
> Then, why the BCM shall allocate #31 in step g) ?

Some channel has to be elected, correct? Do you mean: Why is the channel
field
in the Broadcast Channel register? I'm curious about this now.  I don't see
a reason
to have the channel field anymore.  The most significant bit set to 1 tells
other nodes that
the IRM is BCM capable. A set valid bit tells other nodes the broadcast
channel was
allocated. All nodes know the channel is 31. Why have the channel field in
the register?
The negative side-effect is it implies all other nodes should not do
anything until they
read the channel number from the Broadcast Channel register.

> If #31 is allocated by some other applications or by some other nodes,
> what the BCM should do?

I had this question also. After all, how many times have we claimed you
cannot
hardcode the Broadcast channel ... oh well .. previously we did not consider
the
IRM being the BCM.  Certainly we agree that if BCM node was already on the
bus, then there is no danger of some other app allocating channel 31. (see
comment below)
The interesting case is if some existing app is already on the bus and using
channel
31, then a  BCM is added to the bus. The 1394 spec requires no guarantees
that channels allocated prior to a bus reset will be reallocated after a bus
reset.
See page 230 sec 8.4.2.4 "Reallocation of prior isoch resource".

Comment below: To ensure other nodes do not allocate channel 31 before the
IRM
allocates channel 31 for the BCM, I think additional text is needed. The
text should
state the BCM channel is allocated before the IRM accepts any async read or
lock/swap
packets that allocate channels.

> Note that current typical BCM is implemented by the software,
> it is NOT guaranteed that the BCM process is fastest.

True, if the BCM intelligence resides at a higher layer the BCM may take
longer
than the x * 15 ms, where x = 1 to 62. If this is a problem, it only occurs
if the
IP/1394 driver does not get loaded and punch down the BROADCAST_CHANNEL
register before the 15 ms (worse case) timeout. Through implementation
experience
we can learn if 15 ms is indeed enough time, then adjust the spec or improve
the
implementations if 15 ms is not. This is my recollection of what we would
have
done in the previous algorithm had 15 ms not been enough time.

> : g) The broadcast channel manager shall allocate channel number 31
>                                    ================================
> :    from its own CHANNELS_AVAILABLE register and then update its
> :    own BROADCAST_CHANNEL register with the allocated channel number
> :    and set the valid bit to one.    [snip]
>
>
> For others information, 'bcm_ID' field in the
> BROADCAST_CHANNEL register
> is removed by this revision.
> Are there any other big changes?
>
> Best Regards,
>
> Kenji Fujisawa

---

From: Kenji Fujisawa <[email-masked]>
Date: Wed, 5 May 1999 14:23:30 +0900

Myron,

My concern is not 15ms timer, but following additional restriction
you described.

>> it is NOT guaranteed that the BCM process is fastest.

On the other hand, CHANNELS_AVAILABLE register may be implemented
by the hardware (such as OHCI).
I think adding a restriction above is a burden.

If any channel can be used by the BCM, I personally agree with the
revision although I still need more consideration.

Best Regards,

Kenji Fujisawa