Download Full Paper

CHAPTER 2. TESTBED DESIGN
experimentation, the various interfaces that enable a smooth cooperation of the components (marked with an ? in figure 2.3 on the preceding page, the scripting languages
and the centralized data management employed.
2.3.1 Integration and Specification of Algorithms
An algorithm consists of a fixed sequence of one or more modules as illustrated in
figure 2.5 on page 31 and figure 2.2 on page 12. These modules can be pre- and postprocessing modules, the main algorithm module and so on. Each module gets its predecessors output as input. The first module’s input is the input file for the whole algorithm
and the last module in the sequence writes the output file for the algorithm as a whole.
The data stream between the modules is realized via temporary files.
In what follows the integration and specification of modules and algorithms into the
testbed is addressed. The discussion comprises the various interfaces that should, sometimes must be complied to. The two main interface formats the testbed requires are the
output format the modules should adhere to when run last in an algorithm’s module
sequence to enable subsequent statistical analysis of the results and the command line
interface used to address the module binaries on the command line which is mandatory.
An optional extension to this interface is the provision to output the specification of the
parameters and arguments for doing so.
Modules
A module is defined as being part of an algorithm. Only modules actually exist as binary
executables and hence can be executed. In the following, the notion module in used to
refer to the meaning of being part of an algorithm as well as to the meaning of being the
executable binary that implements this part and which can be executed by the system
by calling it with parameters. Sometimes, in order to make things clearer, the latter
meaning is denoted by (module) executable, too. A module is supposed to expect its
input via an input stream realized as a single input file and outputs its computation
results into a single stream, again realized as an output file. The information about
which files to use in addition to other information needed by the module is passed as
parameters. Parameters are represented as command line arguments on the level of
the executable. Figure 2.4 on the next page illustrates this procedure. A module can
be viewed as a black box, which the testbed executes with given parameter values and
provision of a proper input file and which returns a file for further handling by the
testbed.
As pointed out before, in order to run arbitrary modules by the testbed and in order for
the testbed to establish the flow of data from a single input source sequentially through a
sequence of modules that form an algorithm, each module must heed a common interface.
14