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?

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services




