search

art-daq / artdaq

Other
0 stars 3 forks source link

Support the (proto)DUNE DFO Model in artdaq #134

Closed eflumerf closed 2 years ago

eflumerf commented 2 years ago

This issue has been migrated from https://cdcvs.fnal.gov/redmine/issues/22529 (FNAL account required) Originally created by @eflumerf on 2019-05-08 02:14:31

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:

Subtasks:

eflumerf commented 2 years ago

Comment by @eflumerf on 2019-05-08 02:15:54

due to changes in a related task: #22530

eflumerf commented 2 years ago

Comment by @eflumerf on 2019-05-08 02:17:31

due to changes in a related task: #22531

eflumerf commented 2 years ago

Comment by @eflumerf on 2019-05-08 02:19:23

due to changes in a related task: #22532

eflumerf commented 2 years ago

Comment by @eflumerf on 2019-05-08 02:21:03

due to changes in a related task: #22533

eflumerf commented 2 years ago

Comment by @eflumerf on 2019-05-08 02:23:56

due to changes in a related task: #22534

eflumerf commented 2 years ago

Comment by @eflumerf on 2019-05-08 02:26:44

due to changes in a related task: #22535

eflumerf commented 2 years ago

Comment by @bieryAtFnal on 2019-05-09 17:27:57

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?

eflumerf commented 2 years ago

Comment by @eflumerf on 2019-05-09 17:36:45

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

eflumerf commented 2 years ago

Comment by @eflumerf on 2019-05-09 17:40:54

due to changes in a related task: #22569