Net2WG/Notes/20080314

From TinyOS Wiki
Jump to: navigation, search

Contents

Net2WG/Notes/20080314 Meeting Notes


Agenda


* Trickle timers in CTP routing engine
* CTP++

Participants


* Om, USC
* Phil, Stanford
* Razvan, JHU

Discussion Notes


Trickle timers in CTP

* Om: I don't have many results yet but there is almost no impact when changing the frequency from 1s to 30s at the root.
* Om: Phil, what was the intention of this trickle timer?

[ ... longer discussion about this ... ]

* Om: How about route updates?
* Phil: It should also use Trickle timers. We should also incorporate Trickle supression.
* Om: Should this be one shot or periodic?
* Phil: It's periodic because there was a bug in the timer that could generate negative intervals.
* Om: Ok, I'll search the mails to find the history reason of this.

[ Phil starts taking notes ]

* Om: Basically, what was happening, you want a randomized timer. So what you need to do is fire in time A, then B-A, where B is the interval length.
* Razvan: So we are talking about trickle.
* Om. Yes. So the bug was, we were firing at A, then A. So 800ms, then 800ms, not 800ms then 224 ms for an interval of 1024ms. The other bug had to do with when the routing protocol does an immediate update, it changes the timer, but doesn't go through the proper trickle timers. So this can cause some inconsistencies. The trickle code assumes it controls when the timer fires, but sometimes routing does it too.
* Om: So what we want to do, is make it so the routing protocol goes through the trickle timers. This requires some code changes on how components maintain trickle state.
* Om: So, Phil, I will probably have some numbers, I've started with TOSSIM, also on the testbed. So some numbers tomorrow. I actually had a question in TOSSIM. Can you post two tasks?
* Phil: Yes.
* Om: When the beacon timer fires in TestNetwork. It posts two tasks, but for some reason the second isn't posted. I'll look into it.
* Om: Moving on to CTP+. I looked at their code, and it seems like they maintain some kind of reverse route.
* Phil: So it's not source routing. What's the routing table size?
* Om: This is kind of relevant, because TYMO is supposed to fill this gap.
* Phil: Does it go up to the root then down, does it skip across the graph?
* Om: They have a max destinations of 5. So the idea is, based on my 10 minutes browsing the code, here is the idea. You make a connect call. So let's say you connect to node 5. You start advertising ETX to that node. You have reverse link information from LEEP, so you start building a reverse route. So it's kind of using CTP.
* Phil: So it's, "5, build a tree," or "I'm building a tree, 5 when you hear it, build a route."
* Om: The latter. So it's a proactive protocol. It's cool they've decided to call it CTP++, but it's not compatible. OK, so that's about CTP++. I'll have Romain take a look.
* Om: So we applied to the Google summer of code program. We provide a list of ideas, and the student picks one.
* Om: Something unrelated, we're trying to get momentum behind imote2 with Brano.
* Om: So is there anything about Deluge.
* Razvan: I did not have time. :(
* Om: I thought it was supposed to all be implemented.
* Razvan: I've mostly been working on the CC2420.
* Om: One other thing: the charter. He thinks we should take bolder initiatives. Push more.