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