[[PageOutline]] [[wiki:GEC21Agenda/OEDL/Experiment1 <-- Back to Experiment 1] | [wiki:GEC21Agenda/OEDL/Experiment3 Next to Experiment 3 -->] {{{ #!html

GEC21 - OEDL Tutorial 2

Overview

This second part shows how to design, execute, and view the results of an experiment, which dynamically reacts to measurements that are collected during its execution.

This experiment demonstrate OEDL’s capability to allow user to define events which will trigger based on measurements produced by resources invovled in the experiment. In other words, if one or more collected measurements reach a specific condition, then the event will trigger and some user-defined tasks will be executed.

In this experiment:

Experiment 2 Overview
Experiment 2 Overview

Step 1 - Design/Setup

For specific help on using LabWiki, please refer to the LabWiki introduction page

The OEDL experiment description

Experiment 2 OEDL Extract
Experiment 2 OEDL Extract

Walk-through the OEDL experiment description

  1. First, a reminder that all details on OEDL are available in the OEDL reference page

  2. loadOEDL (line 16–17). This command includes in your OEDL experiment other external OEDL scripts. In this example, we are loading the definition of a signal generator and ping application (both instrumented with OML)

  3. defProperty (line 19–20). This command defines experiment properties (aka variables), you can set the values of these properties as parameters for each experiment trials, and access them throughout the entire experiment run. In this example, we are defining 2 properties, to hold the name of the resource to use and the target for the ping application.

  4. Some internal variables (line 21). This is a simple Ruby command that defines an array to hold the list of signal peaks throughout the experiment’s execution. As opposed to the above defProperty variables, internal variables cannot be set at the start of each experiment trial (without having to change the content of the OEDL script itself)

  5. defGroup (line 23–36). This command is used to define a group of resources which we will use in this experiment. A group may contain many resources or any other group, and a resource may be included in many groups. This commands may also be used to associate a set of configurations and applications to all resources in a group. In this example, we define a first group ‘Generator’ with only one resource, then we associate an instrumented signal generator to it. This association is done using the addApplication. Furthermore, we also define a second group ‘Pinger’, which contains the same resource as the first group, but which has an instrumented ping application associated to it.

  6. defEvent (line 40–62). This command defines the name of a user’s custom event and the block of conditions which will be used to check if this event should be triggered.
    • First since the measurements are being collected as the experiment is running, we need to specify how frequently the Experiment Controller should query the collected measurements to check for the conditions. This is set using the ‘every:’ parameter of defEvent (in second).
    • Within the condition block we have two different syntax to access some of the collected measurements:
      • one option (line 51) is to use the SQL syntax to directly write a query for the measurement database using the command defQuery. As many experimenter may be familiar with SQL, this option gives them a very flexible mechanism to access any collected data. The caveat is that they need to know the names of the database tables corresponding to their experiment’s measurement points. This is usually of the form “ApplicationName_MeasurementPoint” (e.g. signalgen_sin in line 51.
      • the other option (line 44–45) is to use a Ruby Sequel syntax. The method ms(arg) returns a Measurement Point model, on which any Sequel querying methods can be applied. The resulting query is then passed to the defQuery command.
    • The returned data is an array where each element represents a measurement sample. Each sample is in turn a hash where each key represents a metric of that sample. The remaining of the condition block in this example (line 53–59) checks if the absolute value of the last sample is greather than 0.99, and triggers the event if so.
  7. onEvent (line 64–66). This command declares the set of actions to perform when a specific event is triggered. In this example, the event is our previously defined “SINE_ABOVE_THRESHOLD”. The actions to perform in this case is to select start a ping application. There is another onEvent declaration further (line 68–75), for the event “APP_UP_AND_INSTALLED”, i.e. when all resources are ready to receive commands and all applications associated to them are installed. When this event triggers, we start the signal generator application on the resource within the ‘Generator’ group, then after 60 seconds we stop all applications and terminate the experiment trial.

  8. defGraph (line 77–91). This commands defines the graphs that will be displayed while the experiment trial is running. In this example, we define one graph showing the generated sine values against time, and one table showing the timestamp and RTT of from each sent ICMP ping packet. These graph and table will be updated using measurements enabled in the previous defGroup blocks.

Step 2 - Execute

Experiment 2 Execute Screenshot
Experiment 2 Execute Screenshot
Experiment 2 Running Screenshot
Experiment 2 Running Screenshot

Step 3 - Finish

Experiment 2 Result Screenshot
Experiment 2 Result Screenshot
Database Dump
Database Dump

Help & Additional Resources

}}} ---- [[wiki:GEC21Agenda/OEDL/Experiment1 <-- Back to Experiment 1] | [wiki:GEC21Agenda/OEDL/Experiment3 Next to Experiment 3 -->] ----