Idea #22529
Support the (proto)DUNE DFO Model in artdaq
14%
Description
I'm opening this as a meta-issue to contain the various (and future) pieces of work we have identified as necessary for providing functionality equivalent to the DFO requirement for DUNE.
I have attached images from the meeting today with Kurt, Wes and myself.
Subtasks
History
#1 Updated by Eric Flumerfelt almost 2 years ago
- Due date set to 05/07/2019
due to changes in a related task: #22530
#2 Updated by Eric Flumerfelt almost 2 years ago
- Due date set to 05/07/2019
due to changes in a related task: #22531
#3 Updated by Eric Flumerfelt almost 2 years ago
- Due date set to 05/07/2019
due to changes in a related task: #22532
#4 Updated by Eric Flumerfelt almost 2 years ago
- Due date set to 05/07/2019
due to changes in a related task: #22533
#5 Updated by Eric Flumerfelt almost 2 years ago
- Due date set to 05/07/2019
due to changes in a related task: #22534
#6 Updated by Eric Flumerfelt almost 2 years ago
- Due date set to 05/07/2019
due to changes in a related task: #22535
#7 Updated by Kurt Biery almost 2 years ago
As an initial step toward returning destination information, along with the artdaq::Fragments, from CommandableFragmentGenerator::getNext(), would it be OK to update the RequestReceiver interface to add a method that returns the destination rank for a specified sequence ID?
Another way to phrase this question: do we want to modify the existing RequestReceiver interface to return destination information, along with sequence ID and timestamp information, from the GetRequests() and GetAndClearRequests() methods,
OR
do we want to keep the existing interface signatures and add a new method to fetch the destination for a specified sequence ID?
#8 Updated by Eric Flumerfelt almost 2 years ago
This is a bit trickier than I realized, since the rank is in the header for the request block…For requests from the RoutingMaster, we may want the rank to be in the RequestPacket struct so that multiple destinations’ requests can be in the same block.
Looking at RequestReceiver.hh, I think requests_ and request_timing_ could be combined to a map between sequence_id and a struct containing timestamp, time received, and destination. We could then provide a set of methods for each of those three, and one for returning the struct itself.
#9 Updated by Eric Flumerfelt almost 2 years ago
- Due date set to 05/09/2019
due to changes in a related task: #22569
#10 Updated by Eric Flumerfelt almost 2 years ago
- Tracker changed from Feature to Idea