Project

General

Profile

Bug #11113

Reduce the maximum time that the OnMon AG has to wait to get an event

Added by Kurt Biery almost 5 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Known Issues
Target version:
Start date:
12/09/2015
Due date:
% Done:

100%

Estimated time:
Experiment:
DUNE
Co-Assignees:
Duration:

Description

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.

History

#1 Updated by Kurt Biery over 4 years ago

  • Target version changed from v1_12_14 to artdaq Next Release

#2 Updated by Kurt Biery about 4 years ago

  • Status changed from New to Assigned
  • Assignee set to John Freeman

John,
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.
Thanks,
Kurt

#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.



Also available in: Atom PDF