MAD: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
|||
| (3 intermediate revisions by 2 users not shown) | |||
| Line 3: | Line 3: | ||
The Mesh Adaptation Daemon (MAD) is a simple daemon that collects mesh statistics from the driver or from any other relevant source and responds by adjusting the operating parameters of the wireless network according to some predefined recipes. |
The Mesh Adaptation Daemon (MAD) is a simple daemon that collects mesh statistics from the driver or from any other relevant source and responds by adjusting the operating parameters of the wireless network according to some predefined recipes. |
||
The objective of MAD is to improve scalability and reliability of the XO mesh. There is also a possibility of using adaptation to reduce battery consumption and other benefits will possibly be included on the long run. |
|||
== Overview == |
|||
From a functional point of view, it consists of the following modules: |
|||
* Collector Module - responsible for gathering all useful information (STATUS) upon which adaptation decisions will be performed |
|||
* Configuration Module - reads the STATUS CHARACTERIZATION and ADAPTATION RULES from a configuration file. The former characterizes an STATUS and the latter determines what ACTION should be performed for each given STATUS. STATUS are divided into AXISes (example: power, mobility, etc). At any given point in the time, an AXIS will have a LEVEL. For example, the Power Axis can assume the levels: ac powered; battery powered high, battery power medium, ..., battery powered critical. We would loosely refer to a status as a combination of LEVELs (where each level is implicitly related to an AXIS). An example of a status would be: AC-powered (Power), fixed (Mobility), dense (Denseness), congested (Congestion). |
|||
* Action Module - implement the ACTIONS i.e. change parameters on the mesh to adapt to the current status. |
|||
== |
== MAD Roadmap == |
||
This module periodically (synchronously) polls data from many sources in order to determine the current mesh STATUS. Data sources include: |
|||
* ioctls |
|||
* pseudo file systems (procfs, sysfs, debugfs) |
|||
* other daemons (avahi, etc) |
|||
=== Phase 1 - (A) Formulate, validate and tune the Heuristics and (B) Define the Architecture === |
|||
Irrespective of the mechanism used to detect it, each item probed will be a VARIABLE. One example, is the number of active neighbors that can be inferred from the forwarding route. |
|||
(A) refers to a series of individual mechanics to be formally proposed, validated and tuned. For instance, we want to make the multicast rate as a function of the mesh density. We first need to describe how this can be achieved, i.e. how to define and measure density and what is the mechanism to change the multicast rate. After that, define what is a good function to be used. |
|||
Refer to the [http://wiki.laptop.org/go/MAD_Heuristics MAD Heuristics page] for more detail. |
|||
== Configuration Module == |
|||
This modules reads a configuration file that has three parts: |
|||
(B) which should be conducted in parallel with (A) relates to the actual implementation of MAD, semantically and syntactically. Describing, for instance, the conceptual framework, terminology and going down to the syntax for a configurations file. |
|||
=== Collectors section === |
|||
This section defines a list of VARIABLES and which collector (an external command) is responsible for determining the VALUES for this variable. |
|||
Refer to the [http://wiki.laptop.org/go/MAD_Architecture MAD Architecture page] for more detail. |
|||
=== Characterization section === |
|||
# A list of axises with respective LEVELs. Example: The Power axis could have the following levels: AC powered, Battery powered 90+, battery powered 70+, and so on. These levels can be identified numerically or by a mnemonic (AC, FULL, MEDIUM, LOW, CRITICAL) |
|||
=== Phase 2 - Implement the proof of concept version === |
|||
Possible parameters: |
|||
* Density: Determines the concentration of nodes within the interference (or carrier sensing, or transmission) range |
|||
* Congestion: Determines current (short termed) spectrum usage (airtime availability) |
|||
* Power: Determines if the node is AC powered or battery powered, and if the battery is FULL, LOW, etc. |
|||
* Mobility: Determines if the node is mobile and the general mobility of the mesh. |
|||
Once an heuristic is formally proposed and validated independently, it should be incorporated in the daemon architecture and go though another series of tests. This phase is important not to validate the heuristics (what has happened in phase 1), but to validate (1) the daemon mechanics and (2) the interactions between heuristics. |
|||
# LEVEL characterization. What makes an axis assume a given level. For example: a battery less than 30% full characterizes the level CRITICAL, for the axis POWER. So, a LEVEL will be characterized for a group of VARIABLEs each with certain VALUES (ranges, where applicable). |
|||
# STATUS characterization. Associates a STATUS with a (sub)set of axis that meet certain levels. STATUS may be very abstract (like IN-SCHOOL status) or more concrete (like CONGESTED) and may be formed by one or more axises. |
|||
=== Phase 3 - Implement a production version === |
|||
=== Action Section === |
|||
During phase 2, it will became clear that some parts of MAD should be implemented while others may not and, moreover, it may be the case that some of the heuristics should be incorporated in the driver or the firmware, in order to improve efficiency or reliability. |
|||
# Directives that associate STATUS with ACTIONs. For example, in a congested network do not lower data rates and/or increase the contention window |
|||
# Specification of the ACTIONs. Probably a command that will implement the desired adaptation. |
|||
== Action Module == |
|||
The action module is responsible for reading the status and act accordingly. |
|||
== Configuration file syntax == |
|||
A first idea for the configuration file syntax: |
|||
variable <VARIABLE_1_NAME> <COLLECTOR_1> |
|||
... |
|||
variable <VARIABLE_N_NAME> <COLLECTOR_N> |
|||
axis <AXIS_1_NAME> { |
|||
<LEVEL_1_NAME>{<VARIABLE_1> <VALUE_X>; ... ;<VARIABLE_M> <VALUE_Y>} |
|||
... |
|||
<LEVEL_2_NAME>{<VARIABLE_1> <VALUE_X>; ... ;<VARIABLE_M> <VALUE_Y>} |
|||
} |
|||
axis <AXIS_N_NAME> { |
|||
<LEVEL_1_NAME>{<VARIABLE_1> <VALUE_X>; ... ;<VARIABLE_M> <VALUE_Y>} |
|||
... |
|||
<LEVEL_2_NAME>{<VARIABLE_1> <VALUE_X>; ... ;<VARIABLE_M> <VALUE_Y>} |
|||
} |
|||
status <STATUS_1_NAME> <AXIS_X_NAME> <LEVEL_K> ... <AXIS_Y_NAME> <LEVEL_R> |
|||
... |
|||
STATUS <STATUS_TYPE> <STATUS_N_NAME> <AXIS_X_NAME> <LEVEL_K> ... <AXIS_Y_NAME> <LEVEL_R> |
|||
ACTION <ACTION_1_NAME> <COMMAND_1> |
|||
... |
|||
ACTION <ACTION_N_NAME> <COMMAND_N> |
|||
ADAPT <STATUS_NAME> <ACTION_1> ... <ACTION_N> |
|||
STATUS TYPE, can be "detected" or "user". So, users actions (like clicking on an icon) can characterize status. |
|||
OR *** a user can inform a status, so it is not necessary to have the status_type |
|||
=== An example === |
|||
variable act_neigh /usr/bin/active_neighbors.py |
|||
variable power /usr/bin/power.py |
|||
axis denseness { |
|||
alone{act_neigh=[0]} |
|||
end(act_neigh=[1]} |
|||
sparse{act_neigh=[2-3]} |
|||
low{act_neigh=[4-5]} |
|||
medium{act_neigh=[6-8]} |
|||
dense(act_neigh=[9+]} |
|||
} |
|||
axis power { |
|||
ac{power=[0]} |
|||
battery{power=[1+]} |
|||
battery_full{power=[90-100]} |
|||
battery_high{power=[70-89]} |
|||
battery_medium{power=[50-69]} |
|||
battery_low{power=[30-49]} |
|||
battery_critical{power=[1-29]} |
|||
} |
|||
status fixed power[ac]; perrs[medium |
|||
status low_battery[battery_low or battery_critical] |
|||
action increase_metrics /usr/bin/metrics.py 800 1000 1900 3900 |
|||
action decrease_metrics /usr/bin/metrics.py 700 900 1800 3800 |
|||
adapt low_battery increase_metrics |
|||
adapt fixed decrease_metrics |
|||
Here is the problem (a node can be fixed and low_battery. |
|||
== Using MAD == |
|||
MAD behavior will be determined by its configuration file mad.conf, but it is also possible to inform (force) a given status |
|||
Latest revision as of 16:38, 9 August 2008
|
NOTE: The contents of this page are not set in stone, and are subject to change! This page is a draft in active flux ... |
|
The Mesh Adaptation Daemon (MAD) is a simple daemon that collects mesh statistics from the driver or from any other relevant source and responds by adjusting the operating parameters of the wireless network according to some predefined recipes.
The objective of MAD is to improve scalability and reliability of the XO mesh. There is also a possibility of using adaptation to reduce battery consumption and other benefits will possibly be included on the long run.
MAD Roadmap
Phase 1 - (A) Formulate, validate and tune the Heuristics and (B) Define the Architecture
(A) refers to a series of individual mechanics to be formally proposed, validated and tuned. For instance, we want to make the multicast rate as a function of the mesh density. We first need to describe how this can be achieved, i.e. how to define and measure density and what is the mechanism to change the multicast rate. After that, define what is a good function to be used.
Refer to the MAD Heuristics page for more detail.
(B) which should be conducted in parallel with (A) relates to the actual implementation of MAD, semantically and syntactically. Describing, for instance, the conceptual framework, terminology and going down to the syntax for a configurations file.
Refer to the MAD Architecture page for more detail.
Phase 2 - Implement the proof of concept version
Once an heuristic is formally proposed and validated independently, it should be incorporated in the daemon architecture and go though another series of tests. This phase is important not to validate the heuristics (what has happened in phase 1), but to validate (1) the daemon mechanics and (2) the interactions between heuristics.
Phase 3 - Implement a production version
During phase 2, it will became clear that some parts of MAD should be implemented while others may not and, moreover, it may be the case that some of the heuristics should be incorporated in the driver or the firmware, in order to improve efficiency or reliability.