FireWire broadcast vs. asynchronous modes: "reduced performance" explained

Back in August, we reported on a possible "Mactell drive and FireWire 2.1 conflict." Wire Moore recently came across this item. He informs us that the apparent "conflict" is really due to the two different modes that FireWire can use. This distinction is also covered in Apple TIL article #30520, but Wire's explanation seems a bit clearer to us. So we've posted it here: "In the course of my work on high-performance server I/O for Intel Corp., I talked an engineer who worked at Phillips on the 1394 spec. He described a feature of the spec that explains this reduced performance: 1394 devices can participate on the FireWire network in two ways 1) asynchronous mode 2) broadcast mode. These differ in that asynchronous mode devices contend for access to the network at the time of transmission of each packet, while in broadcast mode some devices are guaranteed a minimum amount of network bandwidth, whether or not they use it. In asynchronous mode, if devices demand more than the available network bandwidth, then traffic backs up at senders due to congestion. This is undesirable in the case of a real-time activities, such as video capture. DV camcorders typically operate in broadcast mode to ensure they'll get the bandwidth they need to push data to the host computer. The negotiation for a quality of service (QoS) can occur at any time by resetting the bus (network) , but typically only occurs when a device joins or leaves the network. Camcorders do not permit selection of the QoS level, nor do they ever renegotiate to asynchronous mode. They negotiate for broadcast at the time they join the net, and if they can't get the demanded QoS an error is generated. The implications are that this reduced performance is not a conflict, but a feature: the camcorder takes a share of the FireWire capacity, whether it uses it or not, as long as it is a member of the network. This explains the reduced performance that gets better when the camcorder is removed from the network." Update: Matt Deatherage takes partial exception to this explanation. (Note: Matt has been covering FireWire matters in the past two issues of the MWJ). Here's an excerpt from what he wrote to us: "For this to be accurate, it would require that when a camcorder grabs an isochronous channel (the word for a portion of the available isochronous bandwidth), the bus sits idle whether a node broadcasts in that reserved bandwidth or not. But that's not the case. If the presence of the camcorder on the bus is slowing things down, the camcorder is using the bus whether you know it or not. The bus will not sit idle with reserved bandwidth if no node is using it. There's a reserved spot for isochronous packets, but a node has to use the spot or someone else will. And while we're at it, camcorders don't use isochronous mode 'to ensure they'll get the bandwidth they need.' They pick isochronous mode because the data they need to transfer is time sensitive. If you miss a frame, the right action is to move on to the next frame, not to retry sending the dropped frame. Async transactions are for when you need guaranteed delivery; isochronous ones are for when time is more important than error correction."