Reduce the maximum time that the OnMon AG has to wait to get an event
Right now, the default inrun_recv_timeout_usec value of 100000 and the loop count of 10 in receiveFragmentFromSharedMemory means that the online monitoring aggregator can get into a state in which is only receives events every 10 msec or so.
This issue came up on DUNE 35-ton when running scope mode in the RCEs and trying to analyze a full second's worth of data in an online monitoring module.
#2 Updated by Kurt Biery about 4 years ago
- Status changed from New to Assigned
- Assignee set to John Freeman
Your work on the dispatcher may have made this issue moot, or maybe the problem still exists. Please check.
It would be nice to remove this artificial limit on the rate that events can be received by the OnMon AG and/or the dispatcher, if it still exists.
#3 Updated by John Freeman about 4 years ago
- % Done changed from 0 to 100
The shared memory Transfer plugin which has replaced the AggregatorCore member functions for transferring fragments via shared memory by construction will check that hasFragment is true once a millisecond regardless of the timeout length - in other words, rather than having a fixed loop count and a check frequency defined by the timeout, we have a fixed check frequency and a loop count defined by the timeout.
#4 Updated by Eric Flumerfelt over 3 years ago
- Category set to Known Issues
- Status changed from Assigned to Closed
- Target version changed from artdaq Next Release to v2_00_00
Putting this in the v2_00_00 release, as I know that this is at least somewhat relevant to the logic in DataReceiverManager as well.