Untitled

New_Project_small.m4v Watch on Posterous

Who am I?

I am a dynamic figure, often seen scaling walls and crushing ice. I have been known to remodel train stations on my lunch breaks, making them more efficient in the area of heat retention. I translate ethnic slurs for Cuban refugees, I write award-winning operas, I manage time efficiently. Occasionally, I tread water for three days in a row.

I woo women with my sensuous and godlike trombone playing, I can pilot bicycles up severe inclines with unflagging speed, and I cook Thirty-Minute Brownies in twenty minutes. I am an expert in stucco, a veteran in love, and an outlaw in Peru.

Using only a hoe and a large glass of water, I once single-handedly defended a small village in the Amazon Basin from a horde of ferocious army ants. I play bluegrass cello, I was scouted by the Mets, I am the subject of numerous documentaries. When I'm bored, I build large suspension bridges in my yard.

I enjoy urban hang gliding. On Wednesdays, after school, I repair electrical appliances free of charge.

I am an abstract artist, a concrete analyst, a systems thinker and a ruthless bookie. Critics worldwide swoon over my original line of corduroy evening wear. I don't perspire. I am a private citizen, yet I receive fan mail. I have been caller number nine and have won the weekend passes. Last summer I toured New Jersey with a travelling centrifugal-force demonstration. I bat .400. My deft floral arrangements have earned me fame in international botany circles. Children trust me.

I can hurl tennis rackets at small moving objects with deadly accuracy. I once read Paradise Lost, Moby Dick, and David Copperfield in one day and still had time to refurbish an entire dining room that evening. I know the exact location of every food item in the supermarket. I have performed several covert operations for the CIA. I sleep once a week; when I do sleep, I sleep in a chair. While on vacation in Canada, I successfully negotiated with a group of terrorists who had seized a small bakery. The laws of physics do not apply to me.

I balance, I weave, I dodge, I frolic, and my bills are all paid. On weekends, to let off steam, I participate in full-contact origami. Years ago I discovered the meaning of life but forgot to write it down. I have made extraordinary four course meals using only a mouli and a toaster oven. I breed prize winning clams. I have won bullfights in San Juan, cliff-diving competitions in Sri Lanka, and spelling bees at the Kremlin. I have played Hamlet, I have performed open-heart surgery, and I have spoken with Elvis.

But I have not yet gone to college.

*shamelessly stolen from reddit

Posted via email from …redemption in a blog

Rationale behind Normandias

With the ubiquitous nature of wireless sensor networks, managing networks consisting of tens thousands of nodes can be very challenging if not impossible. It is for this reason that middleware abstractions have been created to simplify the management of sensor networks. Most middleware solutions can be classified into five main groups; virtual machine based, distributed databases, intelligent agents approach, application oriented, and finally message oriented. The design of Normandias draws upon well tested concepts in these five classes.

Virtual Machine (VM) based approaches like Maté based on TinyOS offer a very flexible approach to application development by allowing dynamic code updates using energy efficient code propagation algorithms but suffer from processing overheads when instructions are translated from Mate to TinyOS executable forms. On the other hand, applications built using the specifications of Normandias are written in NesC thus can be directly executed by Motes without the need for additional interpretation. Another major drawback of VM based systems is the need for sensor network programmers to learn yet another VM specific language (typically assembly language) hindering mass adoption.

In the case of Distributed Database approach, sensing nodes are abstracted into storage nodes where intelligent queries incorporating sensing data, spatial data and other parameters can be issued. Although this approach simplifies the task of retrieving data from sensors, it sacrifices the real time requirements of sensor networks and nimbleness of sensing nodes (in sense and react scenarios).TinyDB for instance uses a controlled flooding mechanism to disseminate queries which is generally considered to be inefficient. In Normandias, nodes designated as leaders have access to Query Processing interfaces thus simplifying query processing without removing the real time property of a sensor network. Another drawback of the database approach is the fact that such systems are typically static, that is cannot be changed after deployment. Other issues include ease of integration with other non-database systems and ability to specify QoS parameters which is important since applications can differ by the volume of data generated. For example, an application tracking temperature changes might require less collaboration since changes are slow in occurrence in contrast to a human tracking application.

Normandias based applications have numerous advantages over intelligent agent, application oriented and message based systems. For the sake of brevity, these are not covered in this blog post.

Normandias: An Introduction

Normandias is a service oriented, ambient aware, and object centered framework specifying a formal interface for constructing a wireless sensor network application. It permits sensor network developers to build “plug and play” applications based on certain specifications thus eliminating the need for an in-depth knowledge of TinyOS or NesC when developing applications. Its plugin based structure guarantees that the latest advances in communication, processing, or collaborative algorithms can be easily incorporated with very little or no change to an application. In the simplest terms, my contribution to sensor networks is the identification of critical services which must be offered in some form across certain classes of sensor applications (environmental monitoring, event detection, and tracking systems) and the abstraction of these services into cohesive interfaces whose sum offers the flexibility and efficiency of node centric programming approaches without its complexity.

An Introduction to Sensor Networks and Cyber-Physical Systems

Download now or preview on posterous

Sensor Networks.docx (218 KB)

Comparison of Some 802.11 Standards

The good fellas at the blogs Gizmodo and Engadget go crazy at the thought of getting WiMax and improved Bluetooth specifications. For this reason, I have created a simple picture to compare these standards to other existing ones in the areas of Range and Data Rate.

HA-OSCAR …attaining technological singularity(é) a step at a time

Its been a year since last winter quarter and once again HA-OSCAR (codenamed: Singularity) is on my projects ‘to do’ list this christmas. Last year, I removed all OSCAR dependencies from HAOSCAR making it a truly standalone high availability solution. This year, conclusion of my google summer of code project for OSCAR I gained a great deal of knowledge in the design of practical and highly modularized software systems that support third party extensibility. With this knowledge, it dawned on me that while HA-OSCAR was a first-rate concept, the way its concept was executed left much to be desired. In its current state, it was inflexible, static and only supported one (1) linux distribution.

With these flaws hampering any chance of wide adoption, I proposed a complete redesign and rewrite of its software. I am happy to say that its redesign was complete on the 30th of October and coding commenced in november. Currently, we are close to achieving milestone one. In this new redesign, a lot of non-standard HA components were replaced most notably ping with Linux-HA’s heartbeat. Some other additions include the inclusion of distributed replication block device (DRBD), Mon-it,  Kickstart & SiS suite and several abstracted components. I also hope to attain full compatibility in this new release with a number of linux distributions (CentOS, Rhel, Fedora, OpenSUSE, Debian, & Ubuntu).

As project lead and chief software architect of this new solution, I enforce strict coding rules to avoid the monstrosity the last HA solution had become. Python’s structure and concept of classes/modules plays a huge role in achieving this. In my next HA post I will discuss the four (4) core subsystems that make up the newly revised HA-OSCAR.

Below is the most recent project roadmap and goals of the new HA-OSCAR:

High Availability (HA) Computing has long been played a critical role in industry mission critical applications. On the other hand, High Performance Computing (HPC) has equally been a significant enabler to the R&D community for their scientific discoveries. With combination of HA and HPC, together will clearly lead to even more benefits to both industry, academic and research entities.

The goal of the HA Project is to create a flexible yet leading edge solution which seeks to provide a combined power of High Availability and Performance computing solution. It should enhance any computing infrastructure such as Webservers, and Clusters by providing the much needed redundancy for mission critical grade applications. To achieve high availability, component redundancy is adopted to eliminate single point of failures. Our HA-project incorporates a self healing mechanism, failure detection, automatic synchronization, failover and fail-back.

Roadmap for HA-OSCAR

…Valete Google

Well, echoing the posts of my fellow gsocers; the google summer of code has ended and my plans for the future might not be as murky as I initially expected. Its been 3 months since we were required to turn in our code samples, and ever since I have moved on to 3 new exciting projects. I will provide more in-depth information about my new engagements in my next blog post. For now here are some information and resources relating to my google summer of code project:

My Google SoC project was to develop and integrate into OSCAR a monitoring framework that was designed by OSCAR’s Oak Ridge National Lab team. The framework would be used by other developers who wish to integrate some form of redundancy in their applications by monitoring the state of various services. Detailed information on how to develop monitoring plugins based on the framework and testing this framework with an exisiting OSCAR installation can be found in the pdf version of this README located in the google repository.

Links:

Google Code Repository

OSCAR

Entrails of the OSCAR Monitoring Framework!

(GSoC update)

After about 3 weeks of coding I am elated to announce the completion of the gathering subsystem in the OSCAR Monitoring framework. The first plugin that made use of the framework was written and successfully updated the monitoring database with data. This plugin makes use of the Round Robin Database created and managed by ganglia

For those not familiar with my project here is a description of the goals of the project and here are the milestones achieved so far:

1. Definition of Schemas and familiarity with the OSCAR code base.

2. Successful implementation of the framework core(Interface to OSCAR Database).

3.  Extension of the core framework to the gathering subsystem.

4. Creation of a ‘oscargather’ (the gathering subsystem initiator).

5. Successful development and testing of an OSCAR component plugin.

With these goals attained so far, I can now being development on the next subsystem “The Actor”. This will supposedly take the monitoring data present in the OSCAR database and interact with the other OSCAR components thereby allowing for a more intelligent and dynamic cluster administration resource!

An Anatomy of the Gathering Subsystem

The monitoring framework is divided into 3 distinct parts:

1. Gathering Subsystem

2. Action Subsystem

3. Driver

This blog post describes the rationale behind the code for the gathering subsystem.

How does it work?

Any OSCAR component which wants to be monitored or can generate monitoring data such as heartbeat, IPMI, PBS_MOM e.t.c provides an xml configuration file which specifies certain properties of that component. This xml file will be located in the Gather subdirectory of the monitoring framework. A visual representation of the directory structure is thus:

When the gathering subsystem is initialized it parses all the “config.xml” files which contains all the configuration data for each component. The parsing is done with the help of the parser. The structure of the xml file will be discussed later.

The “Gather.pm” receives from the parser a hash of values, from this information, it is able to create an Oscar_Monitor table in the OSCAR database with column for each component to be monitored. The naming scheme for these columns will also be discussed later . With the Oscar_Monitor initialized, any component can then call the update method with an xml file and expect its data to be made available through the OSCAR database.

In the process of implementing the proposed framework, I saw that my implementation could not handle monitoring data from simple commands. For example, if I wanted to monitor the disk space available on the compute nodes I should be able to write a script to check this and some how put this information in the monitoring database. The task of putting the information in the Oscar_Monitor table is trivial but finding a way to continuously poll this script after a certain time interval would require the script writer to incorporate features that would ensure the script runs indefinitely so as to update its monitoring information available in the Oscar_Monitor table. Monitoring 10 different components with the C3 suite of commands will require 10 different scripts running indefinitely; eventually taking its toll on the processor. It was because of this problem that I created the oscargather daemon which is independent of the monitoring framework but has the ability to connect to the gathering subsystem to determine which components need to be polled if any and call its script every n seconds which will be specified in the components configuration files.

Starting or stopping the oscargather daemon is done with a simple “service oscargatherd start/stop”. This means all the 10 components which needed to be polled can be terminated or started cleanly by simply using this since each is just a thread of execution in this daemon. The oscargather also plays another vital role; it allows components(polled and non-polled) to be added on the fly by simply restarting the service. This is because restarting the service causes the monitoring framework to reinitialize itself therefore taking into account the new components added.

Structure of the “config.xml”

<?xml version=’1.0′?>

<monitorconfig>

<component> string </component>

<function> string </function>

<polled>Boolean </polled>

<script> string</script>

<time> integer </time>

</monitorconfig>

All components need to contain a config.xml file in the Gather directory.

Component: This is used to specify what component will generate the monitoring data for example you can have “Heartbeat”, “C3”, “IPMI”…

Function: This is a short description of the nature of the data to be generated for example nodestatus (for heartbeat), or diskfree (for C3). This is required because one component can generate monitoring data for 2 different purposes for example you can have C3_diskfree (cexec df –h) and C3_memoryfree (cexec free). In this case C3 is used in 2 different contexts. The naming scheme for each column in the Oscar Monitoring table is <component>_<function>. So for each component, its name and function separated by an underscore is created in the monitoring tables.

Polled: If a component wishes to be polled by the gathering daemon it should set this value to true.

Script: All polled components must specify a script name in this tag.

Time: This refers to the time interval for the polling.

Structure of the “data.xml”

<monitordata>

<column>C3_Diskfree</column>

<data>

<hostname>oscarnode2.xperiment</hostname>

<nodedata>diskfree 120GB</nodedata>

</data>

<data>

<hostname>oscarnode1.xperiment</hostname>

<nodedata>diskfree 140GB</nodedata>

</data>

<data>

<hostname>oscarnode3.xperiment</hostname>

<nodedata>diskfree 10GB</nodedata>

</data>

</monitordata>

Column: Specifies what column in the table to update.

Data: Each of the data tags contains two elements the hostname and nodedata. Hostname is simply the full host name of each compute node. The nodedata tag on the other hand is an anonymous data type meaning it is capable of storing data of any type. With this any generic data can be entered into the monitor table.

A full diagram of the whole system (without an implemented Action subsystem)