Deferred High Level Trigger in LHCb: A Boost to CPU Resource Utilization

Similar documents
L1 and Subsequent Triggers

Stefan Koestner on behalf of the LHCb Online Group ( IEEE - Nuclear Science Symposium San Diego, Oct.

1. Introduction. Outline

The LCG 3D Project. Maria Girone, CERN. The 23rd Open Grid Forum - OGF23 4th June 2008, Barcelona. CERN IT Department CH-1211 Genève 23 Switzerland

The CMS Computing Model

2008 JINST 3 S Online System. Chapter System decomposition and architecture. 8.2 Data Acquisition System

First LHCb measurement with data from the LHC Run 2

Detector Control LHC

b-jet identification at High Level Trigger in CMS

LHCb Computing Resources: 2019 requests and reassessment of 2018 requests

CouchDB-based system for data management in a Grid environment Implementation and Experience

LHCb Distributed Conditions Database

Software and computing evolution: the HL-LHC challenge. Simone Campana, CERN

LHCb Computing Status. Andrei Tsaregorodtsev CPPM

Improving Packet Processing Performance of a Memory- Bounded Application

The evolving role of Tier2s in ATLAS with the new Computing and Data Distribution model

The creation of a Tier-1 Data Center for the ALICE experiment in the UNAM. Lukas Nellen ICN-UNAM

LHCb Computing Resources: 2018 requests and preview of 2019 requests

Summary of the LHC Computing Review

PoS(High-pT physics09)036

The GAP project: GPU applications for High Level Trigger and Medical Imaging

LHCb Computing Resource usage in 2017

Grid Computing: dealing with GB/s dataflows

LCG Conditions Database Project

Front-End Electronics Configuration System for CMS. Philippe Gras CERN - University of Karlsruhe

A generic firmware core to drive the Front-End GBT-SCAs for the LHCb upgrade

LHCb Online System BEAUTY-2002

Evolution of Database Replication Technologies for WLCG

Tracking and flavour tagging selection in the ATLAS High Level Trigger

HLT Infrastructure Commissioning

Use of ROOT in the DØ Online Event Monitoring System

The CMS Event Builder

Trigger and Data Acquisition at the Large Hadron Collider

Track pattern-recognition on GPGPUs in the LHCb experiment

ATLAS NOTE. December 4, ATLAS offline reconstruction timing improvements for run-2. The ATLAS Collaboration. Abstract

THE ATLAS DATA ACQUISITION SYSTEM IN LHC RUN 2

CONTROL AND MONITORING OF ON-LINE TRIGGER ALGORITHMS USING GAUCHO

Multi-threaded, discrete event simulation of distributed computing systems

CMS event display and data quality monitoring at LHC start-up

Control and Monitoring of the Front-End Electronics in ALICE

Implementing Online Calibration Feed Back Loops in the Alice High Level Trigger

The Google File System

Cloud Programming. Programming Environment Oct 29, 2015 Osamu Tatebe

Performance benchmark of LHCb code on stateof-the-art

PoS(EPS-HEP2017)492. Performance and recent developments of the real-time track reconstruction and alignment of the LHCb detector.

Challenges and Evolution of the LHC Production Grid. April 13, 2011 Ian Fisk

MiniDAQ1 A COMPACT DATA ACQUISITION SYSTEM FOR GBT READOUT OVER 10G ETHERNET 22/05/2017 TIPP PAOLO DURANTE - MINIDAQ1 1

A Scalable and Reliable Message Transport Service for the ATLAS Trigger and Data Acquisition System

The Google File System

Full Offline Reconstruction in Real Time with the LHCb Detector

Electronics, Trigger and Data Acquisition part 3

The ATLAS EventIndex: an event catalogue for experiments collecting large amounts of data

PROOF-Condor integration for ATLAS

Andrea Sciabà CERN, Switzerland

Data Quality Monitoring Display for ATLAS experiment

ECFS: A decentralized, distributed and faulttolerant FUSE filesystem for the LHCb online farm

Stephen J. Gowdy (CERN) 12 th September 2012 XLDB Conference FINDING THE HIGGS IN THE HAYSTACK(S)

1 MHz Readout. LHCb Technical Note. Artur Barczyk, Guido Haefeli, Richard Jacobsson, Beat Jost, and Niko Neufeld. Revision: 1.0

CMS High Level Trigger Timing Measurements

Optimizing Parallel Access to the BaBar Database System Using CORBA Servers

Clustering and Reclustering HEP Data in Object Databases

AN OVERVIEW OF THE LHC EXPERIMENTS' CONTROL SYSTEMS

The VERITAS VERTEX Initiative. The Future of Data Protection

Experiment

How to tackle the manycore

Evolution of Database Replication Technologies for WLCG

Status and Prospects of LHC Experiments Data Acquisition. Niko Neufeld, CERN/PH

A generic firmware core to drive the Front-End GBT-SCAs for the LHCb upgrade

Operational experience with the ALICE High Level Trigger

GAUDI - The Software Architecture and Framework for building LHCb data processing applications. Marco Cattaneo, CERN February 2000

Worldwide Production Distributed Data Management at the LHC. Brian Bockelman MSST 2010, 4 May 2010

Application of Virtualization Technologies & CernVM. Benedikt Hegner CERN

New strategies of the LHC experiments to meet the computing requirements of the HL-LHC era

The LHCb upgrade. Outline: Present LHCb detector and trigger LHCb upgrade main drivers Overview of the sub-detector modifications Conclusions

Data handling and processing at the LHC experiments

PCIe40 output interface 01/08/2017 LHCB MINIDAQ2 WORKSHOP - PCIE - PAOLO DURANTE 1

Tales of the Tail Hardware, OS, and Application-level Sources of Tail Latency

FuxiSort. Jiamang Wang, Yongjun Wu, Hua Cai, Zhipeng Tang, Zhiqiang Lv, Bin Lu, Yangyu Tao, Chao Li, Jingren Zhou, Hong Tang Alibaba Group Inc

Conference The Data Challenges of the LHC. Reda Tafirout, TRIUMF

Lustre architecture for Riccardo Veraldi for the LCLS IT Team

Streamlining CASTOR to manage the LHC data torrent

TECHNICAL GUIDELINES FOR APPLICANTS TO PRACE 6 th CALL (Tier-0)

CMS experience with the deployment of Lustre

A L I C E Computing Model

Hall D and IT. at Internal Review of IT in the 12 GeV Era. Mark M. Ito. May 20, Hall D. Hall D and IT. M. Ito. Introduction.

Persistent storage of non-event data in the CMS databases

Grid Computing: dealing with GB/s dataflows

First experiences with the ATLAS pixel detector control system at the combined test beam 2004

The ATLAS Tier-3 in Geneva and the Trigger Development Facility

PoS(EPS-HEP2017)523. The CMS trigger in Run 2. Mia Tosi CERN

The ALICE High Level Trigger

Data Base and Computing Resources Management

Streaming Readout, the JLab perspective. Graham Heyes Data Acquisition Support Group Jefferson Lab

CMS data quality monitoring: Systems and experiences

Clouds in High Energy Physics

Large scale commissioning and operational experience with tier-2 to tier-2 data transfer links in CMS

Big Data Analytics and the LHC

Grid Computing Activities at KIT

NFSv4 as the Building Block for Fault Tolerant Applications

The Google File System

Transcription:

Deferred High Level Trigger in LHCb: A Boost to Resource Utilization The use of periods without beam for online high level triggers Introduction, problem statement Realization of the chosen solution Conclusions M.Frank, C.Gaspar, E.v.Herwijnen, B.Jost, N.Neufeld CERN / LHCb Markus Frank CERN/LHCb CHEP2013, Amsterdam, October 14 th18th 2013

LHCb Online Computing in Numbers Readout Network LHCb Online Computing Infrastructure Substantial resources Spectrometer for b quark analysis at LHC 40 MHz collision rate L0 trigger (hardware) Accept rate: ~ 1 MHz Readout NW: ~ 60 GB/s HLT (software) Accept rate: ~ 2-8 khz Event size: ~ 50 KB Data sources: ~ 350 Event packing: ~ 13 56 Racks ~ 1700 Data handling nodes ~ 200 Controls nodes HLT (expected for 2015): ~ 1600 Nodes ~ 25000 cores ~ 45000 Trigger processes ~ 5000 Infrastructure tasks Markus Frank CERN/LHCb CHEP2013, Amsterdam, October 14 th18th 2013 2

LHCb Online Computing Hardware Storage Cluster - File and Stream handling - Fork data streams Readout Network Switch Switch Switch HLT Farm Partially replicated data streams: parasitic, best effort High Level Trigger Identify the Good the Bad and the Ugly Storage System...... Monitoring Cluster Reconstruction Cluster Low level monitoring High level monitoring with using raw data fully reconstructed events Markus Frank CERN/LHCb CHEP2013, Amsterdam, October 14 th18th 2013 3

The Boost: Possible Gain of Time LHC delivers roughly during 30% of the running period stable beams to LHCb 70% of the time the resources are idle Take advantage of the idle-time Sophisticated event filtering Better selection of 'interesting' events Improved physics results Markus Frank CERN/LHCb CHEP2013, Amsterdam, October 14 th18th 2013

The Roadmap: Benefit from Idle Time Try to defer computing needs to time without beam Save events on the local disk of the worker nodes Need to split high level trigger program 'Moore' ~ 8-9 hours beam time (~1 day) buffering for 1 TB disks Only save preselected events Rejection factor 6: ~1-2 week of buffering Enough to be busy during MD periods First stage component responsible for pre-selection Second stage component for the final event filtering Here I present the supporting infrastructure Not the physics details of this split Next: Introduction of basic concepts used in the realization Markus Frank CERN/LHCb CHEP2013, Amsterdam, October 14 th18th 2013

The Basic Pattern: Buffer Manager Data input Producer Managed shared memory Producers declare events Consumers subscribe to events Buffer Manager Consumer Data output Receive interrupts when data is present Pattern used at all stages Whenever event data have to be moved HLT farm, storage-, monitoringand reconstruction cluster See M.Frank et al., Data Stream handling in the LHCb experiment, CHEP 2007, Proceedings, Victoria, BC Markus Frank CERN/LHCb CHEP2013, Amsterdam, October 14 th18th 2013

The Process Architecture: Worker Node Local disk buffer Single Worker Node 100 % Monitoring Storage / Monitoring HLT1 Data Taking Activity HLT2 Deferred Processing Markus Frank CERN/LHCb CHEP2013, Amsterdam, October 14 th18th 2013 7

Worker Nodes: Remarks (1) HLT1 and HLT2 activities are entirely asynchronous Loose coupling through local disk cache HLT1 must execute real-time HLT2 executes with lower priority HLT2 requires 'offline-quality' calibration Calibration in real-time using fraction of HLT1 accepted events Data monitoring facilities in dedicated farms crucial Markus Frank CERN/LHCb CHEP2013, Amsterdam, October 14 th18th 2013 8

Worker Nodes: Remarks (2) We heavily rely on minimizing resource usage Moore processes execution simultaneously on each worker node Worker node resources are 'over-committed' More processes than cores / hyperthreads Memory scarce (2 GB/core) if not addressed and network accesses during configuration Resource sharing is mandatory Large benefit from copy-on-write (~70% of memory) Trigger processes forked after configuration phase Quick application startup using process checkpointing Markus Frank CERN/LHCb CHEP2013, Amsterdam, October 14 th18th 2013 9

Worker Nodes: Control All processes of one activity on a worker node Need to be started and configured in a well defined order following the states of a finite state machine Are controlled by a dedicated process, which reports to the experiment controls system Consequences for the control of the activities Two independent control trees (next slides) HLT1 + Experiment HLT2 activity Markus Frank CERN/LHCb CHEP2013, Amsterdam, October 14 th18th 2013 10

Controls: Two Separated Control Trees Control flow Data flow Experiment Control...... Storage Monitoring Farm Reconstruction Farm Markus Frank CERN/LHCb CHEP2013, Amsterdam, October 14 th18th 2013 All resources shared HLT subfarm(s) HLT2 Control 11

Controls Issues Experiment controls system implemented in WinCC Commercial SCADA (originally called PVSS) Used throughout the experiment Hardware configuration (slow control) DAQ, Run-Control, Farm operations Partitioning concept realized throughout Traditionally: Parallel DAQ of independent subdetectors while no beam De facto: Deferred trigger processing = Independent DAQ with data from disk => Presence of partitioning concept eased the implementation of deferred HLT processing Markus Frank CERN/LHCb CHEP2013, Amsterdam, October 14 th18th 2013 12

Controls: Parallel Trees in Reality HLT1 Data Taking Activity HLT2 Deferred Processing Markus Frank CERN/LHCb CHEP2013, Amsterdam, October 14 th18th 2013 13

Controls: Parallel Trees in Reality Elements steering/monitoring the experiment hardware HLT1 Data Taking Activity HLT2 Deferred Processing Markus Frank CERN/LHCb CHEP2013, Amsterdam, October 14 th18th 2013 14

Conclusions We managed a redesign of the high level trigger infrastructure to Benefit from time periods without beam Results in a possible increase of 200% time Gained time to be used to improve event selection in the high level trigger The realization was based on two basic concepts Consistent deployment of the Buffer Manager pattern throughout the dataflow The partitioning concept supporting shared computing resources Markus Frank CERN/LHCb CHEP2013, Amsterdam, October 14 th18th 2013 15

Markus Frank CERN/LHCb CHEP2013, Amsterdam, October 14 th18th 2013 16