1 / 17

Routing and Streaming in the HLT

Routing and Streaming in the HLT. TDAQ Week Sander Klous Wednesday, May 17, 2006. StreamTag scenarios (UC01). (Partial) Event. (Partial) Event. (Partial) Event. (Partial) Event. LVL1 Info. LVL1 Info. LVL1 Info. LVL1 Info. Ath / PESA. RoutingTag. RoutingTag. RoutingTag. RoutingTag.

bradleywinston
Download Presentation

Routing and Streaming in the HLT

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Routing and Streaming in the HLT TDAQ Week Sander Klous Wednesday, May 17, 2006

  2. StreamTag scenarios (UC01) (Partial) Event (Partial) Event (Partial) Event (Partial) Event LVL1 Info LVL1 Info LVL1 Info LVL1 Info Ath / PESA RoutingTag RoutingTag RoutingTag RoutingTag StreamTag StreamTag StreamTag StreamTag Ath / CALid LVL2 RoiB Ros/Robin pRos PT L2sv DFM L2pu SFI (partially) build Ath / CALIB Ath / CalStr PT Event LVL1 Info Stream n Stream 1 Stream 2 From LVL1 • Use Case 01 • Events triggered by LVL1 • Bypass LVL2 (force accepted by L2SV) • Based on LVL1 info • Based on statistics • Based on L2pu timeout • RoutingTag build by L2SV • Event and StreamTag build by SFI • Bypass EF SFO Stream selection EFD Input Create RoutingTag B ExtPT Create StreamTag D C Trash ExtPT Output Output

  3. StreamTag scenarios (UC02/UC03/04) (Partial) Event (Partial) Event (Partial) Event (Partial) Event (Partial) Event LVL1 Info LVL1 Info LVL1 Info LVL1 Info LVL1 Info Ath / PESA RoutingTag RoutingTag RoutingTag RoutingTag RoutingTag StreamTag StreamTag StreamTag StreamTag StreamTag Ath / CALid LVL2 RoiB Ros/Robin pRos PT EFD L2sv Input DFM B ExtPT L2pu SFI (partially) build Ath / CALIB D C Trash Ath / CalStr ExtPT PT Event LVL1 Info Output Output Stream n Stream 1 Stream 2 From LVL1 • Use Case 02/03/04 • Events triggered by LVL1 • RoutingTag created by L2SV • RoutingTag info added by L2PU • For UC02: a force accept by L2PU • Accepted by LVL2 • Event (partially-UC04) and StreamTag build by SFI • Bypass EF SFO Stream selection Create RoutingTag Add to RoutingTag Create StreamTag

  4. StreamTag scenarios (UC05-B) (Partial) Event (Partial) Event (Partial) Event (Partial) Event LVL1 Info LVL1 Info LVL1 Info LVL1 Info Ath / PESA RoutingTag RoutingTag RoutingTag RoutingTag StreamTag StreamTag StreamTag StreamTag Ath / CALid LVL2 RoiB Ros/Robin pRos PT EFD L2sv Input DFM B ExtPT L2pu SFI builds event Ath / CALIB D C Trash Ath / CalStr ExtPT PT Event LVL1 Info Output Output Stream n Stream 1 Stream 2 From LVL1 • Use Case 05-B • Events triggered by LVL1 • Accepted by LVL2 • RoutingTag info added by L2PU • Event and StreamTag build by SFI • Accepted by EF • StreamTag info added by EF • If necessary, stripping done by outputTask SFO Stream selection Add to StreamTag Create RoutingTag Add to RoutingTag Create StreamTag Stripping

  5. StreamTag scenarios (UC05-C) (Partial) Event (Partial) Event (Partial) Event (Partial) Event LVL1 Info LVL1 Info LVL1 Info LVL1 Info Ath / PESA RoutingTag RoutingTag RoutingTag RoutingTag StreamTag StreamTag StreamTag StreamTag Ath / CALid LVL2 RoiB Ros/Robin pRos PT EFD L2sv Input DFM B ExtPT L2pu SFI (partially) build Ath / CALIB D C Trash Ath / CalStr ExtPT PT Event LVL1 Info Output Output Stream n Stream 1 Stream 2 From LVL1 • Use Case 05-C • Events triggered by LVL1 • Accepted by LVL2 • LVL2 RoutingTag info added by L2PU • Event and StreamTag build by SFI • Accepted by EF • StreamTag info added by EF • If necessary, stripping done by outputTask SFO Stream selection Create RoutingTag Add to RoutingTag Create StreamTag Add to StreamTag Stripping

  6. StreamTag scenarios (UC06/07) (Partial) Event Event Event (Partial) Event (Partial) Event LVL1 Info LVL1 Info LVL1 Info LVL1 Info LVL1 Info Ath / PESA RoutingTag RoutingTag RoutingTag RoutingTag RoutingTag StreamTag StreamTag 1 StreamTag 2 StreamTag 1 StreamTag 2 Ath / CALid LVL2 RoiB Ros/Robin pRos PT EFD L2sv Input DFM B ExtPT L2pu SFI (partially) build Ath / CALIB D C Trash Ath / CalStr ExtPT PT Event LVL1 Info Output Output Stream n Stream 1 Stream 2 From LVL1 • Use Case 06/07 • Events triggered by LVL1 • Accepted by LVL2 • LVL2 RoutingTag info added by L2PU • Event and StreamTag build by SFI • Accepted by EF • StreamTag info added twice by EF • If necessary, stripping done by outputTask SFO Stream selection Add to StreamTag1 Create StreamTag Routing Routing Add to StreamTag Add to StreamTag2 Duplicating Stripping Note for UC05/06/07 If PT times out, ExtPTs can force accept the event. This event does not contain EF StreamTag information, nor did the LVL2 RoutingTag mark it to “Bypass EF”.

  7. Use Case analysis • The definition of the words “TriggerResult”, “RoutingTag” and “StreamTag”. • RoutingTag and StreamTag are not the same as TriggerResult. • The TriggerResult contains information about which triggers fired. • The “RoutingTag” describes the Route of an event in the HLT. • The “StreamTag” describes the destination(s) stream of an event. • Of course, all three are highly correlated. • Requirements • An event should never end up twice in the same stream. • Hence, the StreamTags of two instances of the same event should be mutually exclusive. • The TriggerResults of two instances of the same event should be identical. • Design implications • Each level guides the next active level in routing/streaming. • Reserved header bits for routing and streaming information. • Duplication of events is only possible in the last stage of the EF. StreamTags in the HLT

  8. A generic StreamTag generation scheme (Partial) Event (Partial) Event (Partial) Event Event (Partial) Event LVL1 Info LVL1 Info LVL1 Info LVL1 Info LVL1 Info RoutingTag RoutingTag RoutingTag RoutingTag RoutingTag StreamTag StreamTag 1 StreamTag 2 StreamTag StreamTag Event Header 8 bit LVL1 Trigger Type 32 bit LVL2 Trigger Info 4 x 32 bit EF Info EFD UC06/07 UC05 and UC06/07 PT1 or PT2 PT2 UC02/03/04 and UC05/06/07 LVL2PU All UCs LVL2SV LVL1 UC01 UC02/03/04 UC05 B/C UC06/07 SFO From ATL-D-ES-0019, raw eformat V3 StreamTags in the HLT

  9. Trigger classes Calibration (missing) Bypass LVL2 (missing) Bypass LVL2PU Calo / muon e/, jet, E Low pT muons CTP priority level Table 11-19, page 392 Missing functionality: Possible duplication warning (1 bit). Bypass EF (1 bit). LVL 2 StreamTag version number (4 bits). Trigger class (16 bits). Table 11-20, page 393, physics TDR. Might choose similar construction as LVL1, where few bits control the meaning of the other bits. Current specifications Event Header 8 bit LVL1 Trigger Type 32 bit LVL2 Trigger Info 4 x 32 bit EF Info 8 bit LVL1 Trigger Type (from draft proposal N. Ellis) Other (i.e. Calibration or Test) Physics 32 bit LVL2 Trigger Info (from ATL-DQ-ES-0076) Specification will change to 64 bits. Needed for partial event building. StreamTags in the HLT

  10. “128 EF BitPattern” (EF status bits) and internal EF routing e20i mu60i j250 Error A Error B muon Calibration LAr Calibration Error C Null pointer 64 bits filled by PESA Athena algorithm: bits of “fired” (0 or 1) TriggerElements according to TriggerMenu in TrigConfDB AND some PESA Steering-specific errors (not “visible” outside PESA) 32 bits filled by CALIB Athena algorithm: “fired” bits (0 or 1) for types of calibration according to DB AND errors specific to the Calibration Athena algorithm 32 bits filled by PSC/DF (outside Athena) various PSC/DF errors, etc. according OKS ConfDB GENERAL IDEA: Mapping from StatusBits to Answers Not distinguish TRIGGER MENU details to avoid connect to TrigConfDB e20i mu60i a FEW DF/Routing Answers as summary of all given set of StatusBits, For example: “Good physics” “Calibration” “Various COMBINATIONS” (e.g. good physics and calibration) “VARIOUS kinds of Error/Debug/ForcedAccept” (MANY !!) j250 BUT be able to use PESA error code bits which CAN be in OKS Error A muon Calibration LAr Calibration Null L2Result … and yet ANOTHER mapping from Answers to Routes ! Null EFResult StreamTags in the HLT

  11. Possible Use Cases/Combinations of StatusBits/Answers/ROUTES: P = “PhysicsAccept” (at least one TE bit “fired”, no Err)  ROUTE “Physics” (no 2nd CalPT) C = “Calibration Accept” (at least one Calibration bit “fired”, no Err)  ROUTE “Calibration” (2nd CalPT) B = EF Bypassed (Bypass from L2, no any processing in EF)  corresponds to ROUTE “P” with flag Bypassed in StatusBits F = Various Types of Forced Accept (from PESA/PSC/OKS)  corresponds to ROUTE “P” with additional details in StatusBits pattern E = ANY Error (in PESA, in Calibration Algorithm or in PSC/PT)  corresponds to ROUTE “P” with flag “DEBUG” in StatusBits pattern (F & E = different Use Cases/streams !!) all possible  useful combinations: P & !C& !E & !F = “pure” P !P & C& !E & !F = “pure” C 2=“both”P & C& !E & !F = ROUTE “P+C” (send both P&C events to 2nd ExtPT task) N!P & !C& !E & !F = nothing needed in this event  TrashTask F & !E& any P & any C = corresponds to ROUTE “P” with details of Forced Accept in StatusBits E& any F & any P & any C = corresponds to ROUTE “P” with flag “DEBUG” in StatusBits So, (algorithm) ANSWERS can be: P, C, 2, E, F, N, B For ROUTING we do NOT need details (i.e. routes “E” = “F” = “P*” with details in StatusBits), so, the possible ROUTES are: P, C, 2, N, B StreamTags in the HLT

  12. PLANS: 1. EF Routing:mapping from StatusBits to Answer PESA Algorithm P.S.C. PT Fill bits in PESA or CALIBR part PESA EF AnswerRoutingTag (from Athena/PSC) (routing/DF path in EFD) 0/1 P=Physics Accept (!Calibration ) P= “pure” Physics (NO 2nd CalPT) 0/1 C=Calibration (! Physics Accept) C = 2nd CalPT (“pure Calibration”) 0/1 2=Calibration AND Physics accept 2= P + C 0/1 E=Error/Debug any Algorithm or PSC 0/1 F=Any ForcedAccept 0/1 N=NOTHING needed N= Trash 0/1 B=EF bypassed CALIBR EF BitPattern (status bits) Fill PSC/DF error bits PSC / DF SECOND configurable mapping in OKS: Answers  Routing In principle the simplest would be 1-to-1 correspondence from Answers to Routes, but we better “move” it from code to OKS for even more flexibility (see next page for ex.) !! CONFIGURABLE MAPPING IN OKS: StatusBits  Answers StreamTags in the HLT

  13. “128 EF BitPattern” (EF status bits) e20i mu60i j250 Error A Error B muon Calibration LAr Calibration Error C Null pointer Calibration bits from TrigDB (not avail. In DF apps) Calibration error bits CAN be in OKS (available for DF) PSC/DF bits – all in OKS PESA error bits CAN be in OKS and available for DF Bits for Physics Trigger Menu defined in TrigConfDB and NOT available in DF Mapping table in OKS configuration file (no TrigDB access): Status Bits ANSWER ( Use Case ) ROUTE EF_BYPASS BB (no PT processing) ANY bit reserved for physicsP ( “pure” Physics ) P PESA Error A F ( Forced Accept type 2 ) P * Any Calibration bits firedC ( “pure” Calibration ) C Calibration and Physics2 ( Phys + Calibration ) 2 “NONE” (Physics nor Calibration) NP * (Forced Accept type 3) Calibration Error B E ( wrong detector ) N (delete: can not be) L2Result absent EP * (debug 1) EFResult PESA lost / created PSC EP * (debug 2) EFResult ANY absent E ( not expected ) N (delete: program crash) e20i mu60i j250 Error A muon Calibration LAr Calibration Null L2Result Null EFResult StreamTags in the HLT

  14. PLANS: universality in the code level • Data / PSC Operation results  fill corresponding status bits and do not take any action on it (do not touch “answer” or “route”) • Configurable mappings “StatusBits  Answer” & “Answers  Routes” should allow flexibility and avoiding any hard coded routing StreamTags in the HLT

  15. 2. SFO Streams: mapping from Answer & S.B. to streams • ROUTING is needed only “internally” inside EF (or L2), so, no need to use it here • The set of all defined TriggerElements is mapped to “Logical Streams” in TrigConfDB (HERE we DO access it !!). The particular FIRED (for this event) TriggerElements in Algorithm BitPattern are translated (using map of TrigDB) to “Logical Streams”. • The SFO configuration in OKS contains file names of SFO streams • With additional mapping (in OKS ? In TrigDB ?) we can translate “logical Streams  stream file names” 2 TrigConfDB DAQ ConfDB (OKS) E gamma “file” p1 e20i “file” p2 1 mu60i muons j250 jets “file” p9 this mapping is also possible - do we need it ? Error A Muon Cal. “file” c1 muon Calibration LAr Cal. “file” c4 LAr Calibration P=Physics Accept (!Calibration) C=Calibration (! Physics Accept) 2=Calibration and Physics Accept E=Error/Debug Any algorithm or PSC F=Any ForcedAccept N=NOTHING needed (N/A) B=EF bypassed Debug “file” D1 Express “file” D2 Null L2Result Null EFResult Monitor “file” Mon StreamTags in the HLT

  16. EF Trigger Info Event Header 8 bit LVL1 Trigger Type 32 bit LVL2 Trigger Info 4 x 32 bit EF Info • Overhead is from various emails/meetings • Physics is from data stream meeting: • http://agenda.cern.ch/fullAgenda.php?ida=a06860 • Other is from Hawkings/Gianotti document StreamTags in the HLT

  17. Summary • Specification of Routing and Streaming in the HLT is completed (after a lot of long discussions). • DataFlow applications do not need access to TrigDB. • OKS does not need knowledge about Trigger Scheme • No hard coded relations, all routing and streaming is done through configuration schemes • Implementation details under discussion • E.g. bit patterns • Write up to be completed (ATL-DQ-ES-0076) • Implementation needs quite some work StreamTags in the HLT

More Related