The D0 online monitoring and automatic DAQ recovery Page: 2 of 8
This article is part of the collection entitled: Office of Scientific & Technical Information Technical Reports and was provided to Digital Library by the UNT Libraries Government Documents Department.
The following text was automatically extracted from the image on this page using optical character recognition software:
Computing in High Energy and Nuclear Physics, La Jolla Ca, March 24-28, 2003
* Do not make excessive requests for the same data
from the same monitor source in short periods of
time. In particular if several copies of the same
display are running, they should share similar
2.1. Monitor System Design
We choose to base our system around a Monitor Server.
Figure 1 is a block diagram of the system. Clients furnish
data, and Displays request the data. The Monitor Server
(MS) sits between the two. The displays do not make direct
connections to the clients. All requests in the system are
driven by the displays. If a particular client's monitor data is
not requested, then the Monitor Server will never request it
from a client.
-Client Monitor Display
Client Server \ ._
Figure 1 : A high level diagram of the monitor
system. Monitor data flows from left to right, and requests
for particular monitor data from right to left. The Monitor
Server (MS) caches replies from the clients.
Monitor data is indexed by three keys: the machine name,
the monitor type, and the item name. The machine name is
the DNS name of the source machine. The monitor type is
the class of monitor client - for example a l3xnode is a
collection of items from a L3 Trigger farm node. Finally, the
item name refers to a particular data item. The data returned
for an item is arbitrary, and be as large or small as desired
(see below). However, the finest grained monitor data
request is a monitor item.
The MS stores the most recent reply from each client in a
data cache. When a display requests data the MS first checks
the cache. If there is a match, the cached data is returned
instead making a new request to the client. The display's
request may optionally specify a staleness time. If the cache
data is older than the staleness time the cache is refreshed
with a request to the client. If no staleness time is specified
in the request a default time of one second is used.
All communication between monitor system components
is over TCP/IP sockets. We use the ACE framework for all
sockets programming . This has the added benefit of
making the code cross platform (the MS is designed to run
on both Windows and Linux).
We have also taken advantage of ACE's multithreaded
programming paradigms (see section 2.2). The threading
was specifically added to take care of timeouts in the clients
with minimal extra programming work. While this will hang
a single display's request for data, it will not hang other
All connections to the MS are persistent. This avoids
overhead involved in setting up new connections. There
exists a web-accessible deamon that acts as a go-between to
the MS for displays that require a short-lived connection (see
The system is designed to recover from crashes and power
outages. The protocol requires both the displays and clients
initiate their connections to the MS. If the connection is
dropped for any reason, the display or client immediately
tries to reconnect. It is possible for a TCP/IP connection to
be broken without being closed. This occurs most frequently
when the MS suffers a power outage. A ping message is sent
by the MS to the client every 10 seconds if there has been no
data request to the client. If the client doesn't see a ping
message every 25 seconds, the connection is dropped.
Without this feature all clients would have to be restarted in
case of a MS failure.
2.1.1. Data Format
All data between the MS and the clients and displays are
XML based. The XML structure is shown in Figure 2. At its
core, the XML consists of a nnnitor item name as the XML
tag. The reply from the client contains the data as the
contents of the tag. We do not maintain a DTD.
<pbar stack _size!>
</luminosity> />196</beam energy>
_ ze!>33.1<!pbar stack _size>
Figure 2 : Sample client XML request and reply. The
upper block contains the XML query sent by the MS to the
client, and the lower block represents the reply from the
client with the data fields filled in.
The data format has been extremely helpful in debugging
and commissioning the system: one can easily read the text
that comes back from a monitor item request from a python
program or similar.
Each monitor item can contain arbitrary data. The client
programmer is encouraged to provide the data in a XML
format, but that is certainly not a requirement. While binary
data is not legal, it is possible to include almost any arbitrary
character using the CDATA XML construct.
All TCP/IP messages are a 32-bit network ordered length
word followed by the contents of the XML in ASCII. No
binary data is sent in either direction.
2.2. Program Design
The block diagram for the MS is shown in Figure 3. The
TCP/IP connection handlers are based on ACE's
Here’s what’s next.
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.
al., A. Haas et. The D0 online monitoring and automatic DAQ recovery, article, April 6, 2004; Batavia, Illinois. (digital.library.unt.edu/ark:/67531/metadc779188/m1/2/: accessed February 21, 2019), University of North Texas Libraries, Digital Library, digital.library.unt.edu; crediting UNT Libraries Government Documents Department.