58
R. Lulli et al.
• the COTS component driver availability and support,
• the software updates distribution and their impacts on the system,
• the support over time.
Following our previous positive experiences, it was chosen the Ubuntu Linux OS
Long Term Support (LTS) distribution more compatible with the SDK (Software
Development Kit) of both the GPU and the DAQ board.
The processing application is a Linux console application implemented in standard
C/C++ with code regarding the GPU written with the Nvidia Compute Unified Device
Architecture (CUDA) extensions. The application architecture is multi-threaded with
every single task (data acquisition, data processing, data storage, system monitoring,
etc.) managed by one or more different threads. Each task has a modular structure
and can be configured in detail at the application startup, reading the configuration
parameters on multiple configuration files. The application can be started by a console
command, a shell script, or a scheduled operation, and its status can be monitored
reading the operations and error log files.
The data processing is carried out following an operation chain that can be configured at the application startup. Each algorithm of the chain can be processed by the
CPU or by the GPUs (if necessary and/or available) depending on the user selection.
The processing results can be encoded in different data formats and saved on the
spectrometer mass memory or sent out by a Network Interface Card (NIC).
An example of a typical SETI processing chain with GPU usage is the following:
1. data acquisition;
2. transfer of the acquired data to RAM;
3. synchronization with the GPUs and transmission of the data to be processed;
4. FFT execution (or other spectrum analysis algorithms if available);
5. boxcar (or other algorithms) execution to reject the filter shape from the spectrum
and other operations on the data;
6. threshold triggering control (with average, moving average or other algorithms);
7. computation result formatting based on the requested output format.
The control application is written in Python to take advantage of language GUI
portability and standardization, as well as its ability to interface with standard C/C++
applications easily.
This application must be used to configure, activate, stop, and control the
processing application. The GUI is organized in different windows, each one configuring or controlling a different aspect of the processing application. The resulting
setup is written on different files red by the processing application at its startup.
Moreover, the control application monitor, the processing application status reading
its output file, and the other information sent back.
Examples of available functionality in the control application are:
• auto-optimization of the processing application based on hardware components;
• dynamic construction of the processing chain;
• configuration of data acquisition and processing parameters;
R. Lulli et al.
• the COTS component driver availability and support,
• the software updates distribution and their impacts on the system,
• the support over time.
Following our previous positive experiences, it was chosen the Ubuntu Linux OS
Long Term Support (LTS) distribution more compatible with the SDK (Software
Development Kit) of both the GPU and the DAQ board.
The processing application is a Linux console application implemented in standard
C/C++ with code regarding the GPU written with the Nvidia Compute Unified Device
Architecture (CUDA) extensions. The application architecture is multi-threaded with
every single task (data acquisition, data processing, data storage, system monitoring,
etc.) managed by one or more different threads. Each task has a modular structure
and can be configured in detail at the application startup, reading the configuration
parameters on multiple configuration files. The application can be started by a console
command, a shell script, or a scheduled operation, and its status can be monitored
reading the operations and error log files.
The data processing is carried out following an operation chain that can be configured at the application startup. Each algorithm of the chain can be processed by the
CPU or by the GPUs (if necessary and/or available) depending on the user selection.
The processing results can be encoded in different data formats and saved on the
spectrometer mass memory or sent out by a Network Interface Card (NIC).
An example of a typical SETI processing chain with GPU usage is the following:
1. data acquisition;
2. transfer of the acquired data to RAM;
3. synchronization with the GPUs and transmission of the data to be processed;
4. FFT execution (or other spectrum analysis algorithms if available);
5. boxcar (or other algorithms) execution to reject the filter shape from the spectrum
and other operations on the data;
6. threshold triggering control (with average, moving average or other algorithms);
7. computation result formatting based on the requested output format.
The control application is written in Python to take advantage of language GUI
portability and standardization, as well as its ability to interface with standard C/C++
applications easily.
This application must be used to configure, activate, stop, and control the
processing application. The GUI is organized in different windows, each one configuring or controlling a different aspect of the processing application. The resulting
setup is written on different files red by the processing application at its startup.
Moreover, the control application monitor, the processing application status reading
its output file, and the other information sent back.
Examples of available functionality in the control application are:
• auto-optimization of the processing application based on hardware components;
• dynamic construction of the processing chain;
• configuration of data acquisition and processing parameters;