[Olsr-dev] Idea for small OLSR improvement

[Markus Kittenberger]

On Sun, Apr 25, 2010 at 12:07 AM, Mitar <(spam-protected)> wrote:

> Hi!
>
> On Sat, Apr 24, 2010 at 11:39 PM, Markus Kittenberger
> <(spam-protected)> wrote:
> > with the vtimes in txtinfo u can now check if "everywhere" all entries
> have
> > acceptable high vtimes all the time *G
> > e.g. never reach below originators.validitytime/2
>
> Why OLSRd does not do this? For example we have everywhere the same
> configuration. So it could assume that originators' configuration is
> the same as its own and check all this stuff and print some warning to
> log or something.
>

so they vtime thing is already a patch against txtinfo, which is not enabled
by default,..

the vtime patch was made for finding/confirming a misconfiguration, of
course its`improveable,..

so feel free *G

extremely simple approach would be to write to syslog whenever something
times out,.. (to get this (i guess) you could already use existing debug
output and grep)

a bit better would be to have a counter inceased every time something goes
under 1/2 of its vtime, and report only nodes that increased this counter
over certain thresholds, but do not not report ones that go directly into
timing out (as it probably really went down,..)

"reducing above idea to the max" would be to check the old vtime, when a new
packet comes in, if it was less than 1/2 of the new vtime, just print a
warning, this requires no new datafields, just 1 LOC for each message
type,..

hmm maybe i will code something like this now *G

> As I started this thread it is obvious that I do not see any problems
 > with routes being left in place even if they do not work anymore. :-)

but i do, and imho some/many other people do aswell,...

but if u don`t care, just set a vtime of virtually infinite for everything
on every node, but please do not whine if u don like the results,.. *G

btw: setting vtime to infinite is not the same as having the last route
forever.

Markus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20100425/04c6ea24/attachment.html>