Presentation for CHEP2000Data Acquisition systems for HEP applications need constant monitoring (online and offline) of their data streams to accomplish several tasks: quality checking, tuning, statistics, pre-analysis. Monitoring tasks can and should use the same tools as data analysis products (conventions, libraries, environments) to reduce training, installation, development and support efforts and -at the same time - to strengthen the liaison between the online and the offline worlds. The ALICE DATE Data Acquisition system available today for R&D and for test beams is fully integrated with the ROOT environment. A simple DAQ-oriented approach and a more complex OO-based model have been developed to allow a variety of programming paradigms and to validate the complete life cycle of monitoring tools, both for online and offline environments

Carena, W

Divià, R

Rademakers, F

Schossmaier, K

Van de Vyvre, P

Vascotto, Alessandro

Zelazowski, K

CERN Document Server

The usage of ROOT for Online Monitoringin the ALICE DATE systemWisla Carena1, Roberto Divia`1, Fons Rademakers2, Klaus Schossmaier1,Pierre Vande Vyvre1 , Alessandro Vascotto1, Krzysztof Zelazowski1For the ALICE Collaboration1 European Laboratory for Particle Physics (CERN), Geneva, Switzerland2 Gesellschaft fu¨r Schwerionenvorschung (GSI), Darmstadt, GermanyAbstractData Acquisition systems for HEP applications need constant monitoring (online and of-fline) of their data streams to accomplish several tasks: quality checking, tuning, statistics,pre-analysis. Monitoring tasks can and should use the same tools as data analysis products(conventions, libraries, environments) to reduce training, installation, development and sup-port efforts and - at the same time - to strengthen the liaison between the online and the offlineworlds. The ALICE DATE Data Acquisition system available today for R&D and for testbeams is fully integrated with the ROOT environment. A simple DAQ-oriented approach anda more complex OO-based model have been developed to allow a variety of programmingparadigms and to validate the complete life cycle of monitoring tools, both for online andoffline environments.Keywords: Monitoring, DATE, ROOT, ALICE1 IntroductionDeveloping the Data Acquisition (DAQ) system for an experiment in High Energy Physics impliesthe accomplishment of several ancillary tasks, such as online control of the quality of the datastreams, fine tuning of hardware and software parameters, gathering of statistics, data pre-analysis.All these jobs are at the same time detached and correlated with the main DAQ system, they arenot under direct control of the main DAQ state machine and do not necessarily obey to the samerules as the DAQ software. However, they need to cope with the data and control patterns comingfrom the online and they must follow several implicit and explicit rules. Moreover, these tasksoften require sophisticated programming environments (tools, libraries, resources, programmingtechniques) that can make development, debugging and integration rather difficult. In this paperwe illustrate how the development of these monitoring processes can be sensibly facilitated byusing the right techniques and programming environments, provided that an appropriate interfacewith the Data Acquisition stream is available.2 Online vs. Offline: two different worlds?Traditionally, High Energy Physics experiments divide their data handling activities into two maincategories: Online and Offline. The Online attribute is given to all components active during thetransfer between the front-end electronics (detector(s), triggers, sensors) and the Permanent DataStorage (hard disk, tape, CD). The Offline activities cover the libraries, algorithms and simulationsessions used before and after the data collecting process. The boundary of this partitioning canvary and it is not unusual to “import” each other’s products whenever needed (e.g. for onlinefiltering of raw event data or for offline decoding of experimental data).Why this separation? The main reason lies in the difference between the online and offlinedevelopment and production environments (platforms, tools, frameworks). However, the currenttrends in hardware and software products are reducing this gap and aim to make it more cul-tural then real. Online and Offline applications can now use similar - if not identical - hardwareplatforms, operating systems (in their standard form or with real-time extensions) and supportlibraries. The same tools and code can now be shared (logically and physically) throughout thewhole collaboration. More performant resources (CPU power, system/auxiliary/permanent stor-age, interconnecting medias, accessories) are available at reasonable costs while the requirementsfor the collection of data from the hardware remain unchanged. The use of cooperating processesand multiple processors makes load distribution and balancing easy to achieve and effective in itsimplementations. It is therefore possible to have a considerable amount of processing power withthe right tools and the needed libraries about everywhere in the experiment. All this should lead toa broader uniformity, a tighter collaboration and a better use of resources throughout the completeprocessing chain.3 The ALICE Data Acquisition and Test EnvironmentThe R&D groups involved in the ALICE [1] collaboration felt the need of a product capable ofproviding an environment suitable for rapid prototyping of hardware and software modules and tosupport the Data Acquisition system for test setups, both at CERN and at external locations. Tomeet this requirements, the ALICE DAQ team at CERN developed the ALICE Data Acquisitionand Test Environment (DATE) [2]. DATE provides the tools, libraries and skeletons needed forthe quick setup of a test acquisition system, for its integration in multi-detector environments andthe development of the ancillary utilities needed for control and monitoring. Available on severalUnix platforms (Solaris, AIX, OSF-1 and Linux), DATE uses a parallel processing approach andrelies on Unix Interprocess Communication (IPC) features such as shared memory, semaphoresand multi-process locking.The main Data Acquisition process follows a well defined procedure under the strict controlof the DATE global state machine. For what concerns monitoring, more flexibility must be grantedand therefore a standard skeleton is not provided. What is available instead is a set of libraries thatallow a liaison between the raw data stream(s) and the monitoring task(s). This liaison permitsmonitoring from the same CPU responsible for the generation of the online data stream, fromother CPUs part of the same Data Acquisition system (e.g. the event builder or the run controlhost), from CPUs connected to but not part of the DAQ system and from non-DAQ streams, suchas Permanent Data Storage medias (tapes, CDs, etc) or replay of online data stream sources. DATEprovides libraries and tools for all the above styles of monitoring on all platforms where a DAQsystem can be implemented. Furthermore, libraries with reduced capabilities are available forother Operating Systems, where only remote or file monitoring can be performed. This allows“foreign” machines to process raw data coming from the live DAQ stream or from PermanentData Storage systems such as the Central Data Recording (CDR) facility available at CERN.4 Features and limitations of the DATE monitoring schemeMonitoring activities within a Data Acquisition system based on DATE must have little impacton the main experimental data stream. Several “fall-through” paths have been provided to avoidoverhead whenever monitoring is not active (either disabled or without clients). Transfer of eventsbetween the online and the monitoring streams has to be performed as smoothly as possible andshould not sensibly affect the global behaviour of the DAQ system. Other important features of theDATE monitoring scheme allow to effectively select only the desired events as soon as possiblein the transfer process (to offload CPU, system resources and communication medias). Severalselection mechanisms are available, based on the type of event, on user-defined attributes and ondifferent policies and aging algorithms.The chosen design of the DATE monitoring system prevented the development of featuresthat may have introduced a negative impact on the overall performances. Monitoring clients canreceive only one stream at a time and do not combine their requests to offload the charge on thenetwork. Finally, the format of the data exchanged via the DATE monitoring scheme followsclosely the same conventions used for the readout and recording stages. The output is not trivial todecode and it is most likely incompatible with what higher level facilities - such as visualisation,features extraction and filtering algorithms - expect to receive.5 The ALICE ROOT frameworkA High Energy Physics collaboration such as ALICE must define a framework suitable for thedevelopment and the support of complex data production and data analysis environments. Thisframework must offer an adequate set of tools and libraries allowing the creation, interpretation,manipulation and visualisation of data objects coming from the Data Acquisition and from sim-ulation sessions. Furthermore, this framework must be available on all the platforms - hardwareand software - in use by the collaboration. At CERN, the choice of ALICE went mainly to HP-UX hosts and commodity PCs running Linux, although other types of platforms such as Solarisand AIX are also in use, especially for online tasks. Note that we are talking about different im-plementations of the Unix Operating System, so a common Unix approach could be envisaged.However, a Unix implementation may differ from another in several details and this can makecode portability across different platforms quite tricky. High-level functions and libraries may notbe available under the same form. Tools such as editors, compilers, data access routines, may notbe consistently available.Looking for a solution to the above problems, the ALICE collaboration decided to use theROOT package[3] (see also http://root.cern.ch) and to propose it as a part of the commonLHC framework. We believe that ROOT is an ideal environment to introduce physicists quicklyto the world of Objects and C++. ROOT has the capability to handle efficiently large amounts ofdata objects (accessible via their individual attributes) and includes a remarkable set of librariesfor producing histograms, plots, graphics, data visualisation and interaction with the OperatingSystem. ROOT provides a built-in C++ interpreter that allows fast macro prototyping and offersan good environment to learn and use C++. The availability of ROOT on all the major platformsin use in ALICE gives an optimal common development and run-time environment, independentfrom the hardware and software architectures.6 DATE/ROOT monitoring scheme: implementationWe decided to put DATE and ROOT together in order to achieve the following goals: reducedtraining for the Online environment, uniformity of coding conventions, use of standard libraries(system and ALICE-specific), independence from the Operating System, use of special ROOTcapabilities for inspecting and debugging Objects.Our first step was to convert the existing DATE monitoring libraries into sharable objects(to allow their dynamic loading within the ROOT framework). This gave a working environmentsuitable for simple monitoring programs getting and handling raw DATE events. However, thisapproach introduces some conflicts between DATE and ROOT, as they share - and need completecontrol over - several system resources (semaphores, process control, sockets).To avoid this interference, we have decided to use a more complex model, where a specially-tailored Object - called Monitoring Module - would provide an enhanced paradigm to access DATEmonitoring streams. Based on a set of separate cooperating actors, this new model also extendsthe capabilities of the basic approach. At first we adopted the same mechanisms used by DATE(multiple processes using shared memory segments and system semaphores). Unfortunately theresult did not suit very well the ROOT architecture and we therefore switched to a new methodbased on Unix sockets. This implementation proved to satisfy our requirements while providing areasonable efficiency. Data copying is reduced to the minimum possible and events requested bymultiple monitoring modules are transferred from DATE into the ROOT environment only once.Modules belonging to different processes (either different ROOT sessions or different processesusing pre-compiled ROOT environment) do share actors and event data. DATE events are con-verted into ROOT objects using a copy-less approach that makes objectification rather efficient,so efficient that we have proved to be more effective to objectify at the destination rather then atthe source. While it is still possible to use the traditional monitoring approach (where the processstops and waits for the next available event), we provide a more Object-Oriented paradigm wherethe module needs to be subclassed to create an extended ROOT environment: this allows the ap-plication to run the ROOT system event loop while handling the DATE monitoring stream(s). TheMonitoring Module is now available within the standard DATE kit on Solaris and Linux, withporting to AIX in progress. Finally, the Monitoring Module was used to develop a utility calledEventBrowser. This tool allows the dynamic inspection of any DATE Data Acquisition systemstarting from the upper level down to the last byte of the monitoring stream, to explore the struc-ture the DAQ streams and to perform some simple statistics. The EventBrowser proved to bereliable and effective, and it is now part of the standard DATE distribution kit.7 ConclusionWe have been impressed by the effectiveness of the ROOT environment, by its features (the inter-active compiler, the online inspection of ROOT objects, the whole framework) and by the ease ofintegration between the DATE monitoring scheme and ROOT. Never before we had such a pow-erful framework available on all sorts of hosts (from the small Data Acquisition front-end cardsup to the central development cluster). Developing, debugging and validating C++ code has beencompleted efficiently. We had to play a bit with the ROOT environment to find the right way ofdoing things and this gave us several hints on the proper way to integrate ROOT in online environ-ments, where efficient interactions with external actors are required. We ourselves have been ableto develop our monitoring application quickly and effectively. We think that ROOT is an excellenttool to integrate Online and Offline activities within the ALICE collaboration and this justifies ourefforts to offer an efficient and reliable liaison between ROOT and DATE.References1 ALICE Technical Proposal for A Large Ion Collider Experiment at the CERN LHC,CERN/LHCC/95-71, 15 December 19952 ALICE DATE V3.5 User’s guide, ALICE internal note INT-99-46, December 19993 R.Brun and F.Rademakers, ROOT - An Object Oriented Data Analysis Framework, Pro-ceedings AIHENP’96 Workshop, Lausanne, September 1996, Nucl. Inst. & Meth. in Phys.Res. A 389 (1997) 81-86.

The Usage of ROOT for Online Monitoring in the ALICE DATE System

Abstract

Similar works

Full text

Available Versions

CERN Document Server