[Olsr-dev] Idea for small OLSR improvement

[Markus Kittenberger]

hmm afaik this was already explained a while ago on this list,..
but on time more (-;

the vtime is the time this information will (still) stay in olsrd
database,..

that means if no new "olsr-packet" regarding this
link(tc),neighbour(hello),hna,mid comes in, this entry will timeout (that
means removed from database) in vtime seconds,.. (and corresponding routes
will then get removed at next disjkstar run)

how long a new the informations of a new incoming "packet" will be valid
depends on the validity time the originator of this packet has configured
(in its olsrd.conf)

that means if u specify tcvaliditytime of 50 seconds on node A, and e.g. a
tcInterval of 10 seconds,
without any packetloss everywhere in the mesh the vtime of A should never go
below 40,... (and of course not go over 50)

of course you will have some packetloss, but as long as every 5th packet
makes its way to every node in your mesh, evrything is still fine,..
(btw. 50:10 is just an exmaple. and having validity times only 5xinterval is
imho no good idea in typical/larger networks)

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

so you can check if your actually used validity times and intervals of the
various olsrd message types match your network size/topology/average packet
losses/etc.

e.g. large sparse networks, will require long validity times, as packet loss
plays a big role,
while dense networks are very immune to packetloss.

that also means if dense networks grow values could easily stay the same,
but in sparse networks the would need adoption!!
(especially when you started with small validity times)

which validity time u choose is usually a trade off between how
stable/reliable routing u want at the most distant and worst connected parts
of the mesh.
vs. how long u want information about routers an links that don`t exist
anymore to be lying around and potentially even getting used for routing
(resulting in routes that will very likely not work,... )-;)

Markus

p.s when using fisheye use larger tc validity times!!

On Sat, Apr 24, 2010 at 11:05 PM, Jernej Kos <(spam-protected)>wrote:

> Hi!
>
> On Sat, 2010-04-24 at 15:15 +0200, Mitar wrote:
> > Hi!
> >
> > On Sat, Apr 24, 2010 at 2:34 PM, Markus Kittenberger
> > <(spam-protected)> wrote:
> > > did u check how close to timing things are (ether is an compile time
> flag to
> > > enable display of timeouts intxtinfo) (see txtinfo header file)
> >
> > Timings? Kostko, could we add this into our monitor?
>
> What exactly is this reported VTime ?
>
> --
> Jernej Kos <(spam-protected)>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20100424/9ab8e2b3/attachment.html>