Subject: BCM & Asynchronous Stream Question

From: Dimitris Staikos <[email-masked]>
Date: Wed, 12 May 1999 13:48:58 +0300

Please accept my apologies if you see part of this message for
the second time. Several people I know have not received the
original posting, and since I got no comment/response to it,
I fear that something went wrong in the original post.

== Original Post ================================
Doesn't the BCM election process (99-005r1.pdf) contradict the
recommendation set by P1394a draft 2.0 paragraph 9.10?
Paragraph 9.10 _recommends_ that a bus reset should not be
issued by software/firmware for 2 seconds after the last bus reset.

We don't think it's nice if P1394a itself recommends something
in one paragraph and violates it in another. Additionally we
believe that 9.10 is a good recommendation and may be we should
consider changing it into a requirement.

That would not only give enough time for ANY kind of post-bus-reset
management to complete, but it would avoid the design of
protocols that depend on tight timing like the BCM election
does.

For example the 15 msec mentioned in the BCM election process
might appear to be an eternity for chips, but software timing
services are not at all accurate so this can lead to unexpected
behaviour (for example 2 or more nodes deciding do to forceroot
themselves and do a bus reset at the same time).
========================================

I also have another question:
Could somebody be kind enough to explain why it is better
to overload an existing transaction code in order to implement
asynchronous multicast as asynchronous stream, get the IRM
involved into the picture, define the GASP sub-format, and finally
use a fixed channel number for "asynchronous stream broadcast",
instead of defining a new transaction code for asynchronous multicast,
that has a multicast ID in the header, with ID 0 reserved for
"asynchronous stream broadcast", possibly one or more bits to
control propagation over bridges, and anything else that might
be desired from this feature?

I am sorry if this question sounds naive, but from my point of
view the currently suggested solution is not 'clean', and as a result
problems keep popping up and will keep popping up.

Regards,
---------------------------------------------------------------------------
Dimitris Staikos
[email-masked] (Business mail only please),
[email-masked] (Personal mail), ICQ UIN 169876
Software Systems & Applications Chief Engineer, UniBrain, www.unibrain.com
---------------------------------------------------------------------------
STOP NATO AGGRESSION NOW.
YOUR CHILDREN WILL BE THE NEXT TARGETS.
http://www.serbia-info.com/
http://www.iacenter.org/
http://www.geocities.com/SiliconValley/Sector/7365/english.html
http://alert.eunet.yu/stopnato.html
http://www.bgdconsulting.com/
---------------------------------------------------------------------------

---

From: Peter Johansson <[email-masked]>
Date: Thu, 13 May 1999 01:06:28 EDT

In a message dated 99-05-12 07:01:17 EDT, [email-masked] writes:

<<Doesn't the BCM election process (99-005r1.pdf) contradict the
recommendation set by P1394a draft 2.0 paragraph 9.10? Paragraph 9.10
_recommends_ that a bus reset should not be issued by software/firmware for 2
seconds after the last bus reset.>>

<<We don't think it's nice if P1394a itself recommends something in one
paragraph and violates it in another. Additionally we believe that 9.10 is a
good recommendation and may be we should consider changing it into a
requirement.>>

You're right that this change requires coordination with the rest of P1394a.
Clause 9.10 has already been modified as part of the ballot response process
to point out one particular circumstance---the confirmation of gap_count and
the clearing of gap_count_reset_disable---in which a second bus reset is
ESSENTIAL shortly after a bus reset. In other words, there already exists
sufficient reason to not modify the "should" to a "shall". If the arguments
for the BCM functionality are compelling (and you already understand I think
they are), it is appropriate to further modify clause 9.10.

<<That would not only give enough time for ANY kind of post-bus-reset
management to complete, but it would avoid the design of protocols that
depend on tight timing like the BCM election does.>>

I don't believe the revised BCM contention process "depends" upon tight
timing; the 15 ms backoff was retained solely as a heuristic to reduce
traffic after a bus reset.

<<For example the 15 msec mentioned in the BCM election process might appear
to be an eternity for chips, but software timing services are not at all
accurate so this can lead to unexpected behaviour (for example 2 or more
nodes deciding do to forceroot themselves and do a bus reset at the same
time).>>

If the BCM candidates both use PHY configuration packets to set RHB at all
nodes (including themselves---no PHY register writes) and both use arbitrated
(short) bus reset, I don't see how more than one node can have it's
force_root variable TRUE at the time of a bus reset.

On the other hand, there's nothing special, in my mind, about 15 ms backoffs.
Because I expect the BCM to be stable (once elected) and eventually expect
the BCM to be pervasive, I'm not overly concerned if the initial
establishment of a BCM takes some time. When two buses are interconnected,
each with their own BCM whose force_root variable is TRUE the likely result
is disruption of isochronous traffic---but this is true today when the only
concern is the cycle master!

The only solution is to have the capabilities needed in the root to be
implemented by the vast majority of devices. One can debate (and we are doing
just that) whether the desired qualities are cycle master and isochronous
resource manager, CM + IRM), or whether the are CM + IRM + BCM---but the key
part of the solution is to keep this qualities simple enough and valuable
enough to insure widespread implementation.

Because of work in P1394.1, I believe that BCM capability is going to be
essential in the bridged environment. Let's start planning for that now.

Regards,

Peter Johansson

Congruent Software, Inc.
98 Colorado Avenue
Berkeley, CA  94707

(510) 527-3926
(510) 527-3856 FAX

[email-masked]

---

From: "Hattig, Myron" <[email-masked]>
Date: Thu, 13 May 1999 10:22:48 -0700

> -----Original Message-----
> Because of work in P1394.1, I believe that BCM capability is
> going to be  essential in the bridged environment. Let's start planning
> for that now.

I echo Peter's belief for 1394 bridges will need the BCM. In addition, the
BCM will
be an integral part of any solution that bridges between 1394 and other
non-1394
links (e.g. Ethernet).

-myron