Update example READMEs

This commit is contained in:
Alexey Rybalchenko
2018-04-30 15:14:50 +02:00
committed by Mohammad Al-Turany
parent 8ebf65c252
commit 2ec55416ba
11 changed files with 85 additions and 119 deletions

View File

@@ -1,12 +1,12 @@
Example 3: DDS
===============
DDS Example
===========
This example demonstrates usage of the Dynamic Deployment System ([DDS](http://dds.gsi.de/)) to dynamically deploy and configure a topology of devices. The topology is similar to those of Example 2, but now it can be easily distributed on different computing nodes without the need for manual socket reconfiguration of the devices.
To make use of DDS functionality the example executables need to find the DDS plugin libraries that are compiled with FairRoot when FairRoot find DDS installed. DDS location is given to CMake as follows:
To make use of DDS functionality the example executables need to find the DDS plugin libraries that are compiled with FairRoot when FairRoot find DDS installed. Custom DDS location can be given to CMake as follows:
```bash
cmake -DDDS_PATH="/path/to/dds/install/dir/" ..
cmake -DDDS_ROOT="/path/to/dds/install/dir/" ..
```
The description below outlines the minimal steps needed to run the example with DDS. For general DDS help please refer to DDS documentation on [DDS Website](http://dds.gsi.de/).
@@ -40,13 +40,13 @@ If you want to deploy on a single host DDS 1.6+ provides a localhost rms plug-in
##### 3. Write DDS topology file that describes which tasks (processes) to run and their topology and configuration.
Take a look at `ex3-dds-topology.xml`. It consists of a definition part (properties, tasks, collections and more) and execution part (main). In our example Sampler, Processor and Sink tasks are defines, containing their executables and exchanged properties. The `<main>` of the topology uses the defined tasks. Besides one Sampler and one Sink task, a group containing Processor task is defined. The group has a multiplicity of 10, meaninig 10 Processors will be executed. Each of the Processors will receive the properties with Sampler and Sink addresses.
Take a look at `ex-dds-topology.xml`. It consists of a definition part (properties, tasks, collections and more) and execution part (main). In our example Sampler, Processor and Sink tasks are defines, containing their executables and exchanged properties. The `<main>` of the topology uses the defined tasks. Besides one Sampler and one Sink task, a group containing Processor task is defined. The group has a multiplicity of 10, meaninig 10 Processors will be executed. Each of the Processors will receive the properties with Sampler and Sink addresses.
The configuration of the channel connection addresses is done by the DDS plugin via the channel names. The task property names must correspond to the channel names (data1, data2), with binding channels writing the properties and connecting channel reading the properties (see the example XML and JSON files).
If `eth0` network interface (default for binding) is not available on your system, specify another one in the topology file for each task. For example: `--network-interface lo0`.
If you chose step 2b earlier, then modify the provided `ex3-dds-topology.xml` in the top that the following lines read as following:
If you chose step 2b earlier, then modify the provided `ex-dds-topology.xml` in the top that the following lines read as following:
```xml
<declrequirement id="SamplerWorker" type="wnname" value=".*"/>
<declrequirement id="ProcessorWorker" type="wnname" value=".*"/>
@@ -67,7 +67,7 @@ dds-server start -s
Agents are submitted with:
```bash
dds-submit --rms ssh --config ex3-dds-hosts.cfg
dds-submit --rms ssh --config ex-dds-hosts.cfg
```
The `--rms` option defines a destination resource management system. The `--config` specifies an SSH plug-in resource definition file.
@@ -80,7 +80,7 @@ dds-submit --rms localhost -n 12
##### 6. Activate the topology.
```bash
dds-topology --activate ex3-dds-topology.xml
dds-topology --activate ex-dds-topology.xml
```
##### 7. Run