[Olsr-dev] Bug in edge detection

Hannes Gredler (spam-protected)
Fri Sep 7 14:43:17 CEST 2007


On Fri, Sep 07, 2007 at 12:34:50PM +0200, Bernd Petrovitsch wrote:
| On Fri, 2007-09-07 at 12:28 +0200, Hannes Gredler wrote:
| > On Fri, Sep 07, 2007 at 10:20:02AM +0200, Bernd Petrovitsch wrote:
| > | > rather than deleting the edge we tweak T_time to an expired value (now_times -1).
| > | 
| > | Much better;-)
| > | 
| > | > if the neighbor set gets found when processing further packets then T_time
| > | > gets overwritten, otherwise it will get deleted when prcessing eventloop
| > | > next time.
| > | 
| > | When is "next time"?
| > | It it's too short, we are deleting the routes anyways.
| > | 
| > | Hmm, the next packet (with the next set of neighbours) will probably
| > | come
| > | "immediately" (read: quite soon). 
| > | If we set the timeout to "now + 1 second" or "now + 0.5 second"?
| > 
| > i have done some testing and figured at that a delay of 1s does not
| > yield that much of improvment - 10s gives a resonable reduction
| > in malloc() churn. for debugging reasons lets keep it at 10s such
| > that we can get some insight why there are those massive edge
| > changes and who is the culprit.
| 
| I'm fine with any value, that "1" and "0.5" were just some numbers (and
| not even uneducated guesses).
| 
| Hmm, just another wild thought: Is it possible that we propagate these
| "false" route changes to others and increase the overall load in the
| rest of the net?

true - as far as i can see this behaviour _the_ major contributor
of churn in the network (at least over here in the funkfeuer cloud).

/hannes





More information about the Olsr-dev mailing list