The CDF data acquisition system for Tevatron Run II Page: 3 of 4
This article is part of the collection entitled: Office of Scientific & Technical Information Technical Reports and was provided to UNT Digital Library by the UNT Libraries Government Documents Department.
Extracted Text
The following text was automatically extracted from the image on this page using optical character recognition software:
rrz nd s ! lll l 111 11IlI
EE ElNI - L[ [19
rc-r~r ]
Or Lar ra
Figure 2: The Level 3 trigger architecture. SCPU: scanner CPU; CV: converter node; PR:
processing node (presently 8 processing nodes per converter node); OU: output node.
An alternative data path exists for calibration runs and debugging purposes: event frag-
ments can directly be sent over Ethernet from the VME readout controller in each front-end
crate to a multi-threaded application running on a Linux PC. This software event builder as-
sembles the events, albeit at a much lower rate than the main event builder, and sends them
to the data logger.
5 Data Logger and Event Monitoring
The events that pass the Level 3 trigger are collected by a logger process [1] running on an
SGI 2200 server. Data are logged in several streams (of the order 4 to 10) to dual-port fiber
channel disk arrays, read from the second port in the computer center, and written to Sony
AIT tapes. In addition to data logging at a sustained rate of 20 MB/s, some of the events are
sent to remote "consumer" processes for online monitoring, at a total rate of up to 10 MB/s.
Sending events to consumers must not impact the logging rate to permanent storage.
The three main components of the consumer system are online monitor analysis pro-
grams, a display GUI to visualize results of the monitoring programs, and display servers to
establish communications between the monitoring programs and the display GUI through sock-
ets. The analysis (monitor) programs are written by subsystem experts in a common framework.
The system is coded in C++ using ROOT packages for physics analysis, network communica-
tions, and graphical manipulations. The display GUI is either run locally in the control room
or remotely. The display and the display server are coded independently of any specific moni-
tors. A total of about 10 core consumer programs are run routinely during data taking; typical
examples are the online event display or consumers monitoring trigger performance.
6 Run Control
The CDF Run Control [2] is the top level application that controls the data acquisition activities
across front-end and trigger VME crates and related service processes (fig. 3). Run Control
is a real-time multi-threaded application implemented in Java 1.3 with several flexible state
machines allowing sequencing and sophisticated error handling and recovery, and controlling
the synchronization across the system. Run Control communicates to its distributed clients
via connections to a commerical publish/subscribe message passing system, SmartSockets by
Talarian. SmartSockets is also used by various Run Control clients to publish monitoring
Upcoming Pages
Here’s what’s next.
Search Inside
This article can be searched. Note: Results may vary based on the legibility of text within the document.
Tools / Downloads
Get a copy of this page or view the extracted text.
Citing and Sharing
Basic information for referencing this web page. We also provide extended guidance on usage rights, references, copying or embedding.
Reference the current page of this Article.
Meyer, Arnd. The CDF data acquisition system for Tevatron Run II, article, August 27, 2001; Batavia, Illinois. (https://digital.library.unt.edu/ark:/67531/metadc717293/m1/3/: accessed April 25, 2024), University of North Texas Libraries, UNT Digital Library, https://digital.library.unt.edu; crediting UNT Libraries Government Documents Department.