Subject: Re: new BCM election process

From: Peter Johansson <[email-masked]>
Date: Fri, 7 May 1999 13:58:52 EDT

In a message dated 99-05-06 15:08:05 EDT, [email-masked] writes:

<<Is there a problem with using the new BCM algorithm but with a dynamically
allocated channel number? This solution removes the need to hard code the
channel number to 31. By not hard coding the channel to 31, we relieve
Kenji/Tom's concerns that some other device may have or get channel 31. Also,
I think dynamic allocation increases the probability of proper operation in
implementations where the BCM and IRM are implemented within different
modules.>>

Yes, there is a difficulty with a dynamically allocated channel number.

The most critical consideration is not the allocation of some channel (any
channel) to serve as a generic (and default) broadcast channel for the
bus---although this is incredibly useful. The killer argument is the P1394.1
need for a way to adjust the frequency of the cycle master on each bus in a
net of bridged buses.

There is ongoing controversy in P1394.1 as to whether or not maitaining
frequency lock across bridges is SUFFICIENT (some are advocating a net-wide
system time and the ability to select the one "best" clock source for house
synchronization) but all of the participants in the discussion agree that
frquency lock is NECESSARY.

We examined a lot of approaches to cycle clock adjustment in P1394.1 and in
the end concluded that only one was workable: a "go fast/go slow" packet
transmitted with isochronous arbitration. OK, one asks, "On what channel?" It
was at this juncture that we realized we needed to consolidate our needs with
related needs from the BCM.

It is important for the clock adjusting node (we expect it to be a bridge
portal) to be able to RAPIDLY resume transmission of adjustment packets after
a bus reset if cross-bridge isochronous traffic is not to be disrupted. It is
not feasible to wait for dynamic allocation of a channel. Hence the need for
what is, in essence, a hard-wired well-known channel number.

But the cow is out of the barn with respect to demanding such a channel
number in a standard. We have to get it by guile, by making the BCM the
IRM---the only node that can guarantee the allocation of a particular channel
number.

In a later EMail Kenji poses the following objection to placing the BCM
functionality at a level where it may GUARANTEE the availability of channel
31:

<<I think it can not be accepted in the real world.>>

In actual fact, I think it's ESSENTIAL that it be accepted in the real world
because it's not at all clear that we have viable alternatives.

At one point in this thread it was suggested that P1394a forbid any node
except the BCM from attempting to allocate channel 31. That might be useful,
but it is only a partial solution. It is only by making the BCM the IRM that
we can enforce the availability of channel 31. And as this feature comes to
be implemented, Tom's concerns that a newly arrived BCM preempts preexisting
programming channel 31 fade into the distance.

One of the challenges of working with any emergint technology is that we do
not always get things "right" the first time. This is practically a given. I
think that the BCM solution that utilizes channel 31 is NOT an ad hoc
solution to a narrow problem but a generic attempt to solve a serious problem
with the LEAST disruption---not necessarily NO disruption (as we didn't have
a crystal ball).

Regards,

Peter Johansson

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

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

[email-masked]

---

From: Kenji Fujisawa <[email-masked]>
Date: Tue, 11 May 1999 17:47:44 +0900

Peter,

>related needs from the BCM.

Would you teach me how often the "go fast/go slow" packets will be
transmitted when the frquencies of the clocks on the buses differ 100ppm?

I'd like to know the rough estimation, such as several packets/sec
or several thousand packets/sec.

Best Regards,

Kenji Fujisawa