Seminar Topic : QoS In Distributed Event Based systems Guide: Prof. Umesh Bellur

First week report

  1. Background reading on distributed systems(Elements of Distributed computing: By Vijay K Garg)
  2. Distributed vs parallel systems and their characteristics
  3. Models of distributed systems-Happened Before,Causality Model
  4. Logical Clocks
  5. Vector Clocks
  6. RMI,RPC Readings from G. Colouris

Second week report

  1. Direct Dependency Clocks
  2. Mutual Exclusions Using timestamps(Lamports Algo),Token Based Algorithms
  3. Dining philosophers Problem
  4. Studying Synchronous algorithms currently

Third week report(17-23 jan)

Reading the background book on DEBS(SPRINGER)

  1. Need Event Based Systems
  2. Terminologies
  3. Notification And Filtering Mechanisms
  4. Content Based Models-Data Model,Filter Model and Routing optimizations
  • Structured
  • Unstructured(currently reading)

4th week report(24jan-2 feb)

I was not able to read much this week. I completed Unstructured Models.

5th week report(3feb - 5feb)

  1. Different Matching Algorithms, like;
  • Counting Algo
  • Brute force

6th week report(6feb - 12feb)

  1. 1Distributed Notification Routing
  • System Model And Basic Framework
  • Valid Routing Algo-holds local subset and Eventual superset validity.
  • Monotone Valid Routing Algos.
  • Different Algorithms:-
    • Flooding
    • Simple Routing
    • Identity Based
    • Covering Based
    • Merging Based
  1. 2Composite Events
  • Enable us to detect events which are not directly related improving the subscriber's ease.
  • Composite Event Detection- Three Q's
    • Modeling The System-through composite event detection automata.
    • How to express the composite events-through composite event language.
    • Architecture of the System
  • Distribution and Detection Policies.

7th week report(13feb - 20feb)

8th week report(28feb - 6mar)

9th week report(7mar-13mar)

10th week report(13mar-20mar)

11th week report(21mar-27mar)

  1. Papers Based On QoS read this week :-

MTP Topic : Sensor Cloud in Pub/Sub Systems Guide: Prof. Umesh Bellur

  1. Monday(6/6/11) :-
  1. Tuesday(14/6/11) :-
  1. Friday(17/6/11) Searching for the actual problem:-
  1. Wednesday(22/6/11) Searching for the actual problem:-
  1. (5/7/11)Formalizing the problem(under progress):-
  1. (21/7/11)Formalizing the problem(under progress):-
  1. (31/7/11) Experiments done with different mote topologies to show their energy consumption.
  1. (4/8/11) Comparison between energy between worst(picking most distant node) and best case(nearest node selection) selection.
  1. (15/8/11) Edited the power profile plugin of for tinyos. More than editting it understood that how it calculates and found the following:-
  • No provision for different power consumptions for different power levels of radio transmission.
  • Added the calculation of remaining battery energy with the assumption that initial energy is equal to two AA batteries(43200 J).
  • As the power consumption is calculated after the simulation, need to find the work around to change the mote selection based on remaining power dynamically.
  • Here are some basic simulations showing the energy consumption for basic setups.simulations
  1. (26/8/11) Did some simulations to show that random selection of motes leading to selection of non optimal paths and motes will result in higher energy consumption.
  • Topology taken was:-5 mote.
  • Mote0 can communicate with 1,2.
  • Mote4 is source sensor and Mote0 is sink, which sends the data to base station through USB cable.
  • Two paths exist b/w Mote0 and Mote4-
    • 0>1>4>1>0(Optimal)
    • 0>2>3>4>3>2>0(Suboptimal)
  • When plotted the power profile for both above scenarios, results shown were not as expected always. The cause of this behavior is to be determined.
  • This is the power profile data.Optimal Suboptimal
  1. (1/9/11) The error wasn't in the way the powerprofile plugin was handling the events related to radio communication. The problem was resolved by setting a one shot timer at transit nodes which detects if that particular node is participating in communication or not. If found not participating, sets it radio off otherwise keeps running its radio.
    • The topology was same as above(topology). A one shot timer running at nodes 1,2,3 if fired before any message transmission by that node, its radio set off saving the un-necessary wastage of energy.
    • Using above mentioned scheme, now the difference is clearly visible when going through less number of hops, energy consumption is less. These are the data files and graph-
  1. (12/9/11) This week i was able to play with the cpu states such as STANDBY, IDLE etc. This led to much low power wastage as the nodes which were sitting idle were sent to the stanby state.
    • Experiments are based on the (topology).
    • Three types of scenarios are used
      1. Single Source with two sensors(optimized path)-0,1,2,3,6,8. DATASET
      2. Two Source of data(optimized path)-0,1,2,3,6,[8,9]. topology DATASET
      3. Two Source of data(load balanced)-0,1,2,3,6,8 and 0,1,2,4,5,7,9. topology DATASET
    • This experiment shows although the energy consumption is less if optimized path is used but the in case of load balanced dissemination path, all nodes share the load.
    • The optimization done here is that, when the message transmission is done, mote goes to a low power state(STANDBY) and on receiving message it agains switches its cpu state.
    • Still the topology taken is not that apt. Need to come up with a topology which includes the use of network by number of users, also to show that sometimes choosing a long path might be beneficial. Topology under consideration is … topology
  1. The link to the current experimental details is experiments.
    • This link shows the comparison between the query life with varying load and number of paths available without any sharing in between the paths.
    • The topology is topology
    • All the motes have same energy(10000mj) to start with.
    • The queryset used is queryset. To vary the load, we just vary the frequency of the queries.
    • This also shows that the overall query life by our algorithm is better even if we schedule the queries by partitioning into two groups of high and low load resp., where load is determined by the number of messages and number of sensings that needed to be done.
    • The following graphs show the summary of results.exp1 exp2
  1. Link to final experiment data exp_data

public/students/vivekvelankar/home.txt · Last modified: 2012/06/11 11:17 by vivekv