Project

General

Profile

Idea #22529

Support the (proto)DUNE DFO Model in artdaq

Added by Eric Flumerfelt 7 months ago. Updated 5 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
05/07/2019
Due date:
% Done:

14%

Estimated time:
(Total: 0.00 h)
Experiment:
-
Duration:

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.

20190507_165208.jpg (958 KB) 20190507_165208.jpg Eric Flumerfelt, 05/07/2019 09:13 PM
20190507_165152.jpg (895 KB) 20190507_165152.jpg Eric Flumerfelt, 05/07/2019 09:13 PM

Subtasks

Feature #22530: Separate Token Reception from RoutingMasterCore into a subclassClosedKurt Biery

Feature #22531: Add destination parameter to DSM::sendFragmentAssigned

Feature #22532: Add acknowledgements to Request protocolResolvedEric Flumerfelt

Feature #22533: Change signature of CommandableFragmentGenerator::getNextAssignedKurt Biery

artdaq Utilities - Feature #22534: Bookkeeping changes for allowing multiple request domains within a subsystemNew

Feature #22535: RoutingNetOutput plugin: A version of BinaryNetOutput that receives Routing TokensNew

Feature #22569: Update RequestReciever's interfaceResolved

History

#1 Updated by Eric Flumerfelt 7 months ago

  • Due date set to 05/07/2019

due to changes in a related task: #22530

#2 Updated by Eric Flumerfelt 7 months ago

  • Due date set to 05/07/2019

due to changes in a related task: #22531

#3 Updated by Eric Flumerfelt 7 months ago

  • Due date set to 05/07/2019

due to changes in a related task: #22532

#4 Updated by Eric Flumerfelt 7 months ago

  • Due date set to 05/07/2019

due to changes in a related task: #22533

#5 Updated by Eric Flumerfelt 7 months ago

  • Due date set to 05/07/2019

due to changes in a related task: #22534

#6 Updated by Eric Flumerfelt 7 months ago

  • Due date set to 05/07/2019

due to changes in a related task: #22535

#7 Updated by Kurt Biery 7 months 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 7 months 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 7 months ago

  • Due date set to 05/09/2019

due to changes in a related task: #22569

#10 Updated by Eric Flumerfelt 7 months ago

  • Tracker changed from Feature to Idea


Also available in: Atom PDF