<div>hmm afaik this was already explained a while ago on this list,..<br>but on time more (-;<br></div><div><br></div><div>the vtime is the time this information will (still) stay in olsrd database,..<br></div><div><br></div>
<div>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)</div>
<div><br></div><div>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)</div><div><br></div><div>
that means if u specify tcvaliditytime of 50 seconds on node A, and e.g. a tcInterval of 10 seconds, </div><div>without any packetloss everywhere in the mesh the vtime of A should never go below 40,... (and of course not go over 50)</div>
<div><br></div><div>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,..</div><div>(btw. 50:10 is just an exmaple. and having validity times only 5xinterval is imho no good idea in typical/larger networks)</div>
<div><br></div><div>with the vtimes in txtinfo u can now check if "everywhere" all entries have acceptable high vtimes all the time *G<br>e.g. never reach below originators.validitytime/2<br></div><div><br></div>
<div>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. </div><div><br></div><div>e.g. large sparse networks, will require long validity times, as packet loss plays a big role, </div>
<div>while dense networks are very immune to packetloss.</div><div><br></div><div>that also means if dense networks grow values could easily stay the same, but in sparse networks the would need adoption!!</div><div>(especially when you started with small validity times)<br>
</div><div><br></div><div>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.</div><div>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,... )-;)</div>
<div><br></div><div>Markus</div><div><br></div><div><div>p.s when using fisheye use larger tc validity times!!</div></div><br><div class="gmail_quote">On Sat, Apr 24, 2010 at 11:05 PM, Jernej Kos <span dir="ltr"><<a href="mailto:kostko@unimatrix-one.org">kostko@unimatrix-one.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi!<br>
<div class="im"><br>
On Sat, 2010-04-24 at 15:15 +0200, Mitar wrote:<br>
> Hi!<br>
><br>
> On Sat, Apr 24, 2010 at 2:34 PM, Markus Kittenberger<br>
> <<a href="mailto:Markus.Kittenberger@gmx.at">Markus.Kittenberger@gmx.at</a>> wrote:<br>
> > did u check how close to timing things are (ether is an compile time flag to<br>
> > enable display of timeouts intxtinfo) (see txtinfo header file)<br>
><br>
> Timings? Kostko, could we add this into our monitor?<br>
<br>
</div>What exactly is this reported VTime ?<br>
<font color="#888888"><br>
--<br>
Jernej Kos <<a href="mailto:kostko@unimatrix-one.org">kostko@unimatrix-one.org</a>><br>
</font></blockquote></div><br>