Return to narrative CVS log

Jump to this file's LXR Page

Up to [CENS] / tos-contrib / sympathy

Works with sympathy_devel now!

Ahas:
1) Knowing number requests vs how many it tried to send vs... helpful!
2) Knowing how many of each type of packet very helpful - often just certain
	type of packet is not making it through!
3) Having events is not very helpful so far - only metrics
4) Giving the positives is helpful as well as the negatives - maybe have
   a file where i summarize positives? but TOO MUCH DATA - how do iake
   it a useful summary - what goes in a useful summary?
5) Setting check period to 2xrequest period.
6) BIST - even for sympathy - by running troubled_node checks!
	- just looking at metrics reported about each app

Solutions:
1) Start/stop topo-data

Problem:
1) Not getting sympathy responses, even from one-hop neighbors, but getting 
beacons from them. 
Measured: 
- number of requests they are getting (they were getting requests),
	they just weren't sending responses.
- then added, number of times tried to send but failed, also very few.

Things that help:
- nice to have space to put some external variables - during pre-dep
  debugging
- should have sympathy periodically send metric info with these
vars - can use this to see if sympathy just not getting tasked or
somethign else going wrong.
- use sympathy request/response as indicator of whether motes can
be reached and be tasked - cuz sympathy uses same routing overlay

2) Not getting sympathy responses
  - see reported number of sympathy requests received - this needs to
  	be periodically just broadcast without being requested.

3) Not getting sypathy respnoses
  - periodically have metrics sent without request

4) Not getting sympathy requests:
  - answer questions:
     - are we getting regular automated metric returns from node?
        - if no: goto check_routing
	- if yes: is node transmitting requested metrics?
	   - if yes: is the node transmitting sympathy events?
	      - if no: is the node receiving sympathy requests?
	         - if no:
	         - if yes: are they continuing to increase even though number
	      		events transmitted are not?
	      - if yes:
           - if no:

      - check_routing:

5) Fault detection: identify nodes that are not receiving sympathy
	requests, or not sending as many event updates as they have 
	received - is this because their last event hours is not
	same as others?
** Separate number requests msgs rcvd into: number requested
    events rcvd vs number requested metrics rcvd, and
    specify number requests sent out!
** for nodes that havent sent many events:
     - check how many events were transmitted compared to
           how many were received!
     - for these nodes, find nodes with same next-hop
     - else check how many requests they received
     - else see if last-event time is just < time-awake (so maybe
         just dont have events to send)

6) Too many errors (caught that with num errors) on nodes with node-2 as a next-hop.
so added jitter to response to flooded response

7) Wasn't getting metrics or data from a node, BUT i was getting
other data packets (beacons/neighbor-lists etc) - so added this to
the test.

8) observe performance degrade (i.e. stop getting data), and then
  node would reboot

Design:
start/stop symp-requests - command-line/status-device
check for reboot! (ensure its not just a roll-over, but a reboot!)

Why is wsn different:
- energy debugging, performance/network usage assertions, 
functionality debugging all collide -
	how do we express those needs/rules -even dynamically, how do you assess

X graph time awake
X graph its fault-category
Classify nodes:
- we are not getting data from node
   - nodes have no data to send
   - data is not getting through
- performance: nodes sending data, but we arent getting a lot of it
- nodes that are fine