Required handling of sequences of RDM broadcast cmds

[eldoMS]

Hi Eric

Separate from EE memory writes, which I agree can be handled as you describe, there are other reasons a responder needs more time e.g. when it is a proxy or bridge/gateway device to where the data should be going.

Such a device can indeed store some or even many SET requests but at some point it can lead to an overrun in some practical device, that is the case I meant to be referring to also.

To the standard defining folks:

With regards to the 10 to 20 ms back-off as Eric is suggesting in practice for a controller to handle the overrun issues, are there plans on integrating in the standard a number as a suggested spec for this, or somehow a way informing a controller on responder capabilities on this point?

Leaving this point open and up to implementation can (and probably will) lead to incompatibilities between equipments that in a large part could be prevented by some agreement and future definition on this point.

A related aspect to this is also that the real life figure of 5 to 20 ms is often sufficient to handle these situations while the ACK_TIMER has a granularity of 100 ms. These large time chunks lead to extraordinary long delays that can be reduced a lot by allowing, in addition to the current definition, some finer grained timing.

Very interested to hear your opinions!

Greetings

Marc

[ericthegeek]

Originally Posted by eldoMS

Such a device can indeed store some or even many SET requests but at some point it can lead to an overrun in some practical device, that is the case I meant to be referring to also.

One option when this occurs is for the proxy to queue up a response with a NACK:NR_PROXY_BUFFER_FULL. For example, if you've gotten too many Broadcast SET FACTORY_DEFAULTS, you can queue up a SET_RESPONSE FACTORY_DEFAULTS NACK:NR_PROXY_BUFFER_FULL. This gives the controller a way to know that the proxy has overflowed.

Fortunately, assuming a reasonable buffer size in the proxy, these conditions are unlikely to occur in the real world. The fraction of broadcast packets in most RDM systems is relatively small. It's quite rare to see more than a handful of broadcast requests back-to-back.

I mostly see broadcast used for:
DISCOVER_UNIQUE_BRANCH
UNMUTE
IDENTIFY OFF

The first two are only for discovery, and since proxies handle discovery on behalf of their proxied devices these can be handled immediately in the proxy and don't need to be queued.

You may see a Broadcast IDENTIFY OFF sent 3 or 4 times back-to-back by a controller (to mitigate lost or corrupt packets), but you won't see hundreds at once.

Originally Posted by eldoMS

With regards to the 10 to 20 ms back-off as Eric is suggesting in practice for a controller to handle the overrun issues, are there plans on integrating in the standard a number as a suggested spec for this, or somehow a way informing a controller on responder capabilities on this point?

The is really an implementation-specific decision. A wired proxy may need 10ms, but a wireless proxy could require 100ms or more. Whatever value got written into the standard, some would say it's too long, and some too short.

Anyone who's designing a controller that makes heavy use of broadcast packets will need to consider the real-world behavior of proxies. Fortunately, other than test equipment, this kind behavior is very rare.