Commit 33851fef authored by Remi Mommsen's avatar Remi Mommsen Committed by Dainius Simelevicius
Browse files

references #180: expand documentation on EvB scripts

parent e244f7a5
......@@ -9,6 +9,9 @@ performance of the event builder. This howto shall document how this
is done. All paths are given relative to the location of this howto
The results of previous measurements are kept at
Environment settings
......@@ -31,7 +34,74 @@ can be run. A sample setting can be found in ''.
Stand-alone functionality tests
The aim of these tests is to test the functionality of the EvB
applications. These test cases should capture basic functionality and
corner cases as far as they can be reproduced in a small setup.
EVB_SYMBOL_MAP should be set 'standaloneSymbolMap.txt'
The test cases are defined in the files found in the
test/cases directory. They are run on a single machine, e.g., the
virtual machine evb-unittests.cms. Some tests are sensitive to timing
and may fail on slower machines. It would be possible to run the tests
on several machines by using a different EVB_SYMBOL_MAP which
distributes the logical names to differnt machines.
The test cases inherit from the class TestCase, which does the heavy
lifting in providing the test infrastructure and utility
functions. Each test case has to provide 2 methods:
- runTest defines the steps executed during the test
- fillConfiguration defines the setup, i.e., the EVM, RUs and BUs
together with their configuration parameters.
The naming convention uses the number of EVM+RUs as the first number,
and the number of BUs as the second. I.e., 1x1 uses one EVM and on BU,
while 2x1 contains an additional RU. Note that the case class name has
to be identical to the file name to make the reflection work.
Some test use data generated inside the EVM/RU, i.e., the 'inputSource'
is set to 'Local'. A dummyFEROL is available in the EvB code base
which allows to emulate the TCP/IP stream otherwise received from the
FEROLs. The dummyFEROL sports several configuration parameters which
allows to emulate errors, e.g., skipped or duplicated events. A
rather sophisticated example can be found in
Before running any tests, you need to start the
process on the local machine which acts as simple deamon starting and
stopping the XDAQ processes: --launcher start
The test cases can be run individually, by executing, e.g., for the case you would run -v 1x1
You can run all tests defined in the cases directory by issuin g --all
Running without the verbose flag only return success or failure. In
the latter case, the last caught error is deplayed. This is mainly
useful to find any tests which fail after code modifications.
The output of the tests is logged to test/logs, which is useful to
find out why a test failed. For each test there are 2 files:
- the .txt file contains the output of the test scripts including the
XML configuration given to the XDAQ processes
- the .log file contains the output as logged by the XDAQ process.
Note that some tests fail occasionally as the desired state is not
reached within the foreseen time. In this case, you best rerun the
test to verify if it succeeds on a second try. The stability of some
of the tests could be improved by using the SOAP replies from the XDAQ
process as used by RCMS. However, this has not been implemented in the
Once you are done with testing and want to release any resources, you
can stop the launchers with --launcher stop
Performance measurements
......@@ -52,6 +122,9 @@ masking any FEDs. Therefore, the FBset should contain only the FEDs
and FEDbuilders which shall be used for the measurements. If this is
not possible, you can edit the local XML file later (see below.)
You can find a FBset filler to create the EvB scaling setups at
Once you have a suitable FBset, you can create the files needed for
running with scripts with e.g.:
......@@ -82,6 +155,10 @@ running with scripts with e.g.:
--daqval changes the relevant parameters to generate a
configuration suitable for daq2val instead of cDAQ
Note that at the time of writing (Sep 2020), the standard configurator
defined in (line 38) does not support the creation of
folded EvB configurations. You need to get a pre-release version from Maciej.
If runs successfully, you will find 3 files in the
output directory:
- pixelFB.xml which contains the full configuration. The file name
......@@ -95,6 +172,10 @@ output directory:
- is a text file giving a short summary of the
configuration. This file is not used by the scripts.
You can find a convenience scripts,
which creates the setups for the EvB scaling setups created
by mentioned above.
In order to save disk space, you can manually gzip the XML file. The
scripts will uncompress the XML file internally in this case.
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment