glehmannmiotto
commented
3 years ago I think that we can assume that trigger record numbers will be sequentially increasing. Nevertheless, I don’t think it is a good idea to rely on this number for the scenario you describe. There is no reason why trigger records should be recorded to disk in order. Due to the large potential difference in size of trigger records it is easy to imagine some small records overtaking other large ones. Therefore I think you need to keep track of the number of outstanding and not yet completed decisions and not just make the difference of trigger record numbers.
On 2 Jan 2021, at 00:18, bieryAtFnal notifications@github.com wrote:
This is somewhat of an interface question, both for the MiniDAQ App and for the full DAQ.
Some background: within the Dataflow part of the MiniDAQ App, we would like to be able to generate an Inhibit message when there are "too many" TriggerDecisions being processed at the same time. ("too many" would be a configurable parameter)
The easiest way to implement this logic would be to compare the Trigger Number of the most recently received TriggerDecision with the Trigger Number of Trigger Record that was most recently written to disk. This difference would give the number of triggers that are "in flight" within the Dataflow subsystem and the "readout" part of the Upstream DAQ subsystem.
However, this simple logic assumes that Trigger Numbers will always increase by one from one Trigger Decision to the next. Will this assumption be satisfied by the TriggerDecisionEmulator that is being developed for the MiniDAQ App?
Independent of that, could/should we suggest that this be a requirement of the interface between the DataSelection and Dataflow subsystems in the full DAQ?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/DUNE-DAQ/trigemu/issues/3, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD6SRU2ZBY7TTZYETXZARWTSXZJ4VANCNFSM4VQTL43Q.
bieryAtFnal
This is somewhat of an interface question, both for the MiniDAQ App and for the full DAQ.
Some background: within the Dataflow part of the MiniDAQ App, we would like to be able to generate an Inhibit message when there are "too many" TriggerDecisions being processed at the same time. ("too many" would be a configurable parameter)
The easiest way to implement this logic would be to compare the Trigger Number of the most recently received TriggerDecision with the Trigger Number of Trigger Record that was most recently written to disk. This difference would give the number of triggers that are "in flight" within the Dataflow subsystem and the "readout" part of the Upstream DAQ subsystem.
However, this simple logic assumes that Trigger Numbers will always increase by one from one Trigger Decision to the next. Will this assumption be satisfied by the TriggerDecisionEmulator that is being developed for the MiniDAQ App?
Independent of that, could/should we suggest that this be a requirement of the interface between the DataSelection and Dataflow subsystems in the full DAQ?