MAD

From OLPC
Revision as of 16:38, 9 August 2008 by Carrano (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search


Pencil.png NOTE: The contents of this page are not set in stone, and are subject to change!

This page is a draft in active flux ...
Please leave suggestions on the talk page.

Pencil.png

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.