Changes between Version 2 and Version 3 of Software/dOML/CollectingMeasurements


Ignore:
Timestamp:
Nov 25, 2007, 11:51:33 PM (15 years ago)
Author:
thierry
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Software/dOML/CollectingMeasurements

    v2 v3  
    22
    33This page is being updated, and is currently not available.
     4
     5
     6[[TOC(heading=Tutorial TOC, Tutorial, depth=2)]]
     7[wiki:Tutorial Back]
     8= Measurements Collection =
     9
     10As introduced in the [wiki:Tutorial/Testbed testbed overview], the '''ORBIT Measurement Framework (OML)''' is a distributed client-server software framework, which enables real-time collection of data from the various applications being executed during an experiment. Figure 1 illustrates this framework.
     11
     12[[Image(OML-overview.png)]]
     13[[BR]] Figure 1.  OML Framework
     14[[BR]]
     15
     16On the experimenter's side, the Node Handler starts an instance of the ''OML Collection Server'', which will listen and collect experimental results from the various nodes involved in the experiment. It then archives these data in a SQL database.
     17
     18On each experimental node, the ''OML Collection Client'' interfaces with each experimental applications. It will collect any required measurements or outputs from these applications, optionally apply some filter/processing to these measurements/outputs, and then sends them to the ''OML Server''. The communication from the multiple ''OML Clients'' on all the experimental nodes towards the ''OML Server'' on the experimenter side is currently done over one multicast channel per experiment (for logical segregation of data and for scalability).
     19
     20
     21The details and "How-To" of such association will be presented in a following part of this tutorial. In the context of this introduction to the testbed, the client-side measurement collection can be viewed as follows. The application will forward any required measurements or outputs to the OML collection client. This OML client will optionally apply some filter/processing to these measurements/outputs, and then sends them to the OML Collection Server (currently over one multicast channel per experiment for logical segregation of data and for scalability)
     22
     23There are two alternative methods for the user to interface their experimental applications with the OML Collection Clients and to define the requested measurement points and parameters. These methods and measurement definitions will be presented in details later in this tutorial.
     24
     25, and, as such, has a client application programming interface (API).  A developer can use this client API through a web interface to define the measurement points and parameters for his or her application.  Measurement points and their frequency of collection are an important part of ones experimental plan.
     26
     27The definition of a measurement point is shown below.   
     28{{{
     29<application id="foo">
     30<measurement-points>
     31  <measurement-point id="group1">
     32    <metric id="rssi" type="float"/>
     33    <metric id="noise" type="float"/>
     34  </measurement-point>
     35  <measurement-point id="group2">
     36    <metric id="throughput" type="int"/>
     37  </measurement-point>
     38</measurement-points>
     39</application>
     40}}}
     41
     42Measurement point definitions are saved as an XML-based configuration file as shown above. The  source code for the measurement client is automatically generated by the web-based OML service that accepts the xml file shown above and returns the autogenerated client API. This API contains application-specific methods that handle type-safe data collection. This source code can be compiled and linked with the application as illustrated by a Makefile and sample application code below.
     43
     44The OML service returns a file called "wrapper" which is a tar+gzipped file containing the src,include and lib directories for the OML client API. The src directory need not be used as we already create a static library for the API (see lib directory). In the Makefile, note that the autogenerated filenames include the application id (foo) from the xml file above. Also note how we use the include and lib directories in CFLAGS and LDFLAGS and then link to the oml_client and the client_api libs in LIBS variable. The oml_client library is installed on the gateway machine and is part of the baseline image.
     45
     46'''Makefile and include file for Measurement Points'''
     47
     48{{{
     49Sample Makefile:
     50APP = foo
     51CC  = gcc
     52CFLAGS  = -g -Wall -I./include
     53LDFLAGS = -L./lib/i386-linux
     54LIBS    = -loml_client -loml_$(APP)
     55SRCS = app.c
     56
     57app: $(SRCS) oml_$(APP).h
     58        $(CC) -o app $(CFLAGS) $(SRCS) $(LDFLAGS) $(LIBS)
     59
     60oml_$(APP).h: $(APP)-def.xml
     61        wget -q http://oml.orbit-lab.org/generator/wrapper --post-file $< -O -\
     62        | tar -xzf -
     63
     64---------------- End of Makefile --------------------
     65
     66./include/oml_foo.h:
     67        int oml_group1(float rssi, float noise);
     68        int oml_group2(int throughput);
     69
     70}}}
     71
     72
     73'''Application Code Sample'''
     74{{{
     75#!c
     76// needs to be called only once
     77initialize_oml(&argc, argv, NULL);
     78
     79if (r_data->send_option == 1) {
     80  buffer->rssi = recv_packet_params.rssi ;
     81  buffer->noise = recv_packet_params.noise;
     82  oml_group1(buffer->rssi, buffer->noise);
     83} else {
     84  log(LOG_ERR, "Unknown receive option! \n");
     85}
     86lost_packets = pck_id.seqnum - old - 1;
     87oml_group2(lost_packets);
     88}}}
     89
     90Because not all measurements are needed and not all measurement samples are needed, '''OML''' supports preprocessing or filtering at source to reduce the amount of reported and recorded data.  Filters are defined by experimenter, and experimenter-provided filters are supported.  Figure 1. below illustrates the client-side data flow.  Collection of and access to the recorded data requires the use of a database schema.  '''OML''' automatically generates the appropriate schema as diagrammed in Figure 2 below.
     91
     92[[Image(clientsidedataflow.PNG)]]
     93
     94Figure 1.  Client-side Data Flow.
     95
     96[[Image(serversideschema.PNG)]]
     97
     98Figure 2.  Server-side DB Schema Generation.
     99
     100
     101
     102The '''Collection Server''' collects experimental results.  There is one instance of the '''Collection Server''' per experiment.  The Berkeley database is used for scalability, and an SQL database is used for persistent data archiving.  One multicast channel per experiment is used for logical segregation of data and for scalability.
     103
     104Besides ORBIT Services, other ORBIT-developed software includes '''Libmac''' and the '''ORBIT Measurement Framework'''.  Each provides procedures that may be called in user-developed applications.  '''Libmac''' is a user-space C library that allows applications to inject and capture MAC layer frames, manipulate wireless interface parameters at both aggregate and per-frame levels, and communicate wireless interface parameters over the air on a per-frame level.
     105
     106The '''ORBIT Measurement Framework (OML)''' has a client/server architecture illustrated in Figure 4 below.  '''OML''' uses IP multicast to send data to the measurement server as it is collected.  '''OML''' includes a client application programming interface (API).  A developer can use this client API through a web interface to define the measurement points and parameters for his or her application.  Such definitions are saved as an XML-based configuration file and source code for the measurement client is automatically generated that contains application-specific methods that handle type-safe data collection.  This source code can be compiled and linked with the application.
     107
     108[[Image(oml-50.png)]]
     109[[BR]]Figure 4. '''OML''' component architecture.
     110
     111User-developed software includes the script for the experiment, the application(s) and any modifications to system software.  The user-developed script for the experiment contains three static components:  the configuration of nodes, the configuration of the application software, and the configuration of the '''ORBIT Measurements Framework and Library (OML)'''.  The application is one or more programs that implement the intended behavior of the active nodes in the experiment.  Modified system software may include modified Linux components or custom device drivers.  Each of these types of user-developed software is covered in more detail in the Testbed Experiments section of this tutorial.
     112
     113