Performance of the final Event Builder for the ATLAS Experiment

Beck, H. P.; Abolins, M.; Battaglia, A.; Blair, R. E.; Bogaerts, A.; Bosman, M.; Ciobotaru, M. D.; Cranfield, R.; Crone, G.; Dawson, J. W.; Dobinson, R.; Dobson, M.; Anjos, A. Dos; Drake, G.; Ermoline, Y.; Ferrari, R.; Ferrer, M. L.; Francis, D.; Gadomski, S.; Gameiro, S.; Gorini, B.; Green, B.; Haberichter, W.; Häberli, Christian; Hauser, R.; Hinkelbein, C.; Hughes-Jones, R. E.; Joos, M.; Kieft, G.; Klous, S.; Korcyl, K.; Kordas, K.; Kugel, A.; Leahu, L.; Lehmann, G.; Martin, B.; Mapelli, L.; Meessen, C.; Meiroşu, Cătălin; Misiejuk, A.; Mornacchi, G.; Müller, Matthias; Nagasaka, Y.; Negri, A.; Pauly, T.; Petersen, J.; Pope, B. G.; Schlereth, J. L.; Spiwoks, R.; Stancu, S.; Strong, J. A.; Sushkov, S.; Szymocha, T.; Tremblet, L.; Ünel, G.; Vandelli, W.; Vermeulen, J. C.; Werner, P.; Wheeler-Ellis, S. J.; Wickens, F. J.; Wiedenmann, W.; Yu, Maoyuan; Yasu, Y.; Zhang, Jinlong; Zobernig, H.

doi:10.1109/rtc.2007.4382747

Cited by 6 publications

(4 citation statements)

References 4 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The synthetic performance benchmarks indicate that ARM SoC performance is similar to the Intel and AMD CPUs currently in use in the Event Builder, for example [6]. In order to pursue this line of investigation, the ATLAS software would have to be recompiled for the ARM instruction set which will be a significant and challenging undertaking.…”

Section: Future Researchmentioning

confidence: 99%

The development of a general purpose ARM-based processing unit for the ATLAS TileCal sROD

Cox

Reed²,

Mellado

2015

J. Inst.

View full text Add to dashboard Cite

The Large Hadron Collider at CERN generates enormous amounts of raw data which present a serious computing challenge. After Phase-II upgrades in 2022, the data output from the ATLAS Tile Calorimeter will increase by 200 times to 41 Tb/s! ARM processors are common in mobile devices due to their low cost, low energy consumption and high performance. It is proposed that a cost-effective, high data throughput Processing Unit (PU) can be developed by using several consumer ARM processors in a cluster configuration to allow aggregated processing performance and data throughput while maintaining minimal software design difficulty for the end-user. This PU could be used for a variety of high-level functions on the high-throughput raw data such as spectral analysis and histograms to detect possible issues in the detector at a low level. High-throughput I/O interfaces are not typical in consumer ARM System on Chips but high data throughput capabilities are feasible via the novel use of PCI-Express as the I/O interface to the ARM processors. An overview of the PU is given and the results for performance and throughput testing of four different ARM Cortex System on Chips are presented.

show abstract

Section: Future Researchmentioning

confidence: 99%

The development of a general purpose ARM-based processing unit for the ATLAS TileCal sROD

Cox

Reed²,

Mellado

2015

J. Inst.

View full text Add to dashboard Cite

show abstract

“…The DataFlow system [7] is responsible for moving the data that succeeded the Level-1 selection to the HLT, and transferring the accepted data to data storage. It is functionally decomposed in four building blocks: the ReadOut System (ROS), the RoI Collection, the EB and the Event Filter I/O.…”

Section: B Dataflow System Descriptionmentioning

confidence: 99%

Integration of the Trigger and Data Acquisition systems in ATLAS

Riu

Abolins

Adragna

et al. 2007

2007 15th IEEE-NPSS Real-Time Conference

View full text Add to dashboard Cite

Abstract-During 2006 and spring 2007, integration and commissioning of trigger and data acquisition (TDAQ) equipment in the ATLAS experimental area has progressed. Much of the work has focused on a final prototype setup consisting of around eighty computers representing a subset of the full TDAQ system. There have been a series of technical runs using this setup. Various tests have been run including ones where around 6k Level-1 pre-selected simulated proton-proton events have been processed in a loop mode through the trigger and dataflow chains. The system included the readout buffers containing the events, event building, second level and third level trigger algorithms. Quantities critical for the final system, such as event processing times, have been studied using different trigger algorithms as well as different dataflow components.

show abstract

“…T HE ATLAS Trigger and Data Acquisition (TDAQ) system is based on three levels of online event selection [1], [2], [3]. Each trigger level refines the decisions made at the previous level and, where necessary, applies additional selection criteria.…”

Section: Introductionmentioning

confidence: 99%

“…About 2% of the event data volume needs to be accessed by the LVL2 trigger processing farms. After LVL2, the event is fully assembled by the Event Builder [3], [4], [5] and then sent to the last stage of the online selection, the Event Filter. The Event Filter employs offline algorithms and methods, adapted to the online environment.…”

Section: Introductionmentioning

confidence: 99%

The data-logging system of the trigger and data acquisition for the ATLAS experiment at CERN

Battaglia

Beck

Dobson

et al. 2007

2007 IEEE Nuclear Science Symposium Conference Record

Self Cite

View full text Add to dashboard Cite

Abstract-The ATLAS experiment is getting ready to observe collisions between protons at a centre of mass energy of 14 TeV. These will be the highest energy collisions in a controlled environment to-date, to be provided by the Large Hadron Collider at CERN by mid 2008. The ATLAS Trigger and Data Acquisition (TDAQ) system selects events online in a three level trigger system in order to keep those events promising to unveil new physics at a budgeted rate of ∼200 Hz for an event size of ∼1.5 MB. This corresponds to a reduction of O(10 5 ) from the initial bunch-crossing rate of 40 MHz at nominal operating conditions. This paper focuses on the data-logging system on the TDAQ side, the so-called "Sub-Farm Output" (SFO) system. It takes data from the Event Filter farm, which is the third level trigger, and it streams and indexes the events into different files, according to each event's trigger path. The data files are moved to CASTOR, the central mass storage facility at CERN. The final TDAQ data-logging system has been installed using 6 Linux PCs, holding 24 disks of 500 GB each, managed by three RAID controllers on each PC. The data-writing is managed in a controlled round-robin way among three independent filesystems associated to a distinct set of disks, managed by a distinct RAID controller. This design allows fast I/O, which together with a high speed network permits to minimize the number of SFO nodes. We report here on the functionality and performance requirements on the system, our experience with commissioning it and on the performance achieved.

show abstract

Performance of the final Event Builder for the ATLAS Experiment

Cited by 6 publications

References 4 publications

The development of a general purpose ARM-based processing unit for the ATLAS TileCal sROD

The development of a general purpose ARM-based processing unit for the ATLAS TileCal sROD

Integration of the Trigger and Data Acquisition systems in ATLAS

The data-logging system of the trigger and data acquisition for the ATLAS experiment at CERN

Contact Info

Product

Resources

About