The Crystal Experiment
Our CAMAC controller consisted of a board which, when inserted on the ISA bus of a computer, could connect to as many as seven different CAMAC crates, each containing up to 22 different specialized devices connected to measuring instruments.
This board was mapped on a known set of ISA bus memory addresses through which a user could send commands to each individual instrument and retrieve the responses. UNIX permits access to physical memory addresses only at the kernel level: it was clear that we needed a set of software routines dedicated to the interaction with the DAQ board, usually called a device driver, to insert into the Linux kernel.
Though aware of the existence of kernel-level device drivers, none of us knew exactly how to write one. (All this happened a few months before the appearance of the good article by Alessandro Rubini. See Resources .) We then decided to ask for help on the comp.os.linux.hardware newsgroup, and less than 24 hours later we were contacted by Ole Streicher, a German researcher who sent us the source code of a device driver he wrote for a different CAMAC controller (see Resources ). Adapting it to our board was a matter of a couple of days, and then experimental data were happily flowing in and out of our DAQ system: the Linux option was finally open.
The ability to dynamically load and unload modules in the kernel, a feature which had been introduced in Linux only a few months before, was of great help in the driver development phase.
From the user's point of view, the CAMAC system was now visible via simple files, one for each different crate, which could be opened, closed, written to and read from. We also provided an interface library in order to hide the low-level details of the CAMAC operations and facilitate code writing. The presence of both the gcc C compiler and the f2c FORTRAN-to-C converter allowed us to provide both a C and a FORTRAN version of this interface library, in order to allow our colleagues to write their own DAQ programs.
Using this library we wrote the main DAQ program which was able to automatically set the run conditions, control the movement of the radioactive source via a serial link to a step motor, send light pulses to calibrate the light sensors, and collect the data coming from the DAQ system and analyze them on the fly. To write the user interface, we used the Tcl/Tk package (see Resources ): all the program controls appeared on a graphical window which could be opened on any X display (Figure 4).
Figure 4. This is a snapshot of our PC screen during an actual DAQ run. In the center you can see the Tcl/Tk-based control interface while the window on the left shows the data collected during the run. The histogram, updated in real-time during the run, is created using the HBOOK and HPLOT packages of the CERN libraries.
Parallel to the DAQ program, we wrote a program to monitor the status of the data acquisition and of some important parameters such as the number of events collected, event rate and average values. With a scientific libraries package called CERNLIB (see Resources ) developed at CERN, freely available along with its source code and widely used in the high-energy physics community, we interfaced the monitor program to a simple analysis facility. This allowed us to access interesting information and execute some preliminary analysis even while the DAQ was being done (Figure 4).
An important factor for a DAQ system is the time performance. If the controlling software is too slow, data may be lost and the time required to collect a useful amount of data can grow to an unacceptable level.
We found the only time-limiting factor in our system was the conversion time of the ADC board; the operating system could easily keep pace with the DAQ task, even while running several other user tasks. This is very important, as this year our bench will move from a prototype level with a single active DAQ chain to an industrial-strength production facility where multiple measurements will proceed in parallel in order to quickly handle all of the many thousands of crystals needed for the CMS experiment.
In practice, we measured the time to execute a single CAMAC operation to be on the order of 10 microseconds, large with respect to the 1.5 microseconds minimum CAMAC operation time, but very good for an inexpensive board such as the CAEN A151 and much lower than the ADC response time of 110 microseconds.
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- Stunnel Security for Oracle
- The Firebird Project's Firebird Relational Database
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide