<br><br><div><span class="gmail_quote">On 6/19/08, <b class="gmail_sendername">Henning Rogge</b> <<a href="mailto:hrogge@googlemail.com">hrogge@googlemail.com</a>> wrote:</span><blockquote class="gmail_quote" style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0; margin-left: 0.80ex; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex">
On Thu, Jun 19, 2008 at 17:09, Markus Kittenberger<br> <<a href="mailto:Markus.Kittenberger@gmx.at">Markus.Kittenberger@gmx.at</a>> wrote:<br> >> Do you think we could use this two arguments to get reasonable values for<br>
 >> your<br> >> model ?<br> ><br> > this two parameters are very important for the size/layout of the first<br> > linear window,.. and the first averaging function,..<br> ><br> > one question, how do you now the hello timeout of your neighbours, do they<br>
 > put them into their hello messages?</blockquote><div><br>sorry i of course meant the hello interval not the timeout,.<br>and if its transmitted, everything is fine,..<br><br></div><blockquote class="gmail_quote" style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0; margin-left: 0.80ex; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex">
> the exponentially part of the window, has it`s own tuning paramters, which<br> > once we found good values should be quite ok for most networks<br> > maybe one total history length/duration parameter makes sense (in seconds)<br>
 > (may be useful for example if you know you`ve got some (too long shots) of<br> > 5ghz bridges which tend to repeatedly-completely fall out in bad weather<br> > situations)<br> > (the old window size could be even used as input for this<br>
 > (total_history_duration=hello_interval*window_size)<br><br>I would like an algorithm which automatically choose it's parameters<br> by using the hello timeout.</blockquote><div><br>this is no problem, i only stated that some advanced parameters (targetet to the exponential history part) in extend to the dynamical hello interval are needed, but they will only rarely/never need to be changed by the end user, if we found good default values,..<br>
<br>so it can configure itself based on the hello interval,..<br><br></div><blockquote class="gmail_quote" style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0; margin-left: 0.80ex; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex">
Java would be great (I have done more coding in Java than in c ;) )</blockquote><div><br>at the moment i tend to an javascript attempt, reusing a framework i currently build for an javascript horst-alike tool, and an existing realtime lq chart i made some months ago, to get real link (sesing) data from the router where it came from,..<br>
so it can be "installed" on fff routers to show a grpah of current lq/etx implementation and some graphs resulting from other interpretations of sensing the same link,..<br></div><br><blockquote class="gmail_quote" style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0; margin-left: 0.80ex; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex">
> if this difference (from a reboot) is detectable depends on whether the<br> > olsrd starts with sequence number 0 or with a random number,..<br><br>olsrd starts with a random number I think.</blockquote><div><br>hmm, changeable behaviour? <br>
but, its dirty anyway, because what if a reboot happens just before the sequence numbers reach their upper limit<br></div><br><blockquote class="gmail_quote" style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0; margin-left: 0.80ex; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex">
 > the problem is that when the algorithm finds out it was a reboot he has<br> > already filled parts of the history with the low lq values, he generated<br> > with every lq timeout<br><br>yes, if the reboot happens fast enough this might be a problem.</blockquote>
<div><br>fast enough? <br><br>you mean faster than the link timeout or what?<br></div><br><blockquote class="gmail_quote" style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0; margin-left: 0.80ex; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex">
 > of course it may make sense to keep history longer then the link timeout,<br> > depending non how short the link timeout is<br><br>Not good... when the link times out the datastructure we are using to<br> store our information will be freed.</blockquote>
<div><br>it depends how long history is, whether i dislike this or not,..<br><br>but imo its a good idea to completely stop routing over a link, much earlier than to drop any information about it,..<br></div><br><blockquote class="gmail_quote" style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0; margin-left: 0.80ex; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex">
 > a link timeout (at which definitely no route will use this neighbour) makes<br> > much sense with this history algorithm,..<br> > than for example while after 12 seconds the lq has dropped to 50% of his<br> > "original" value<br>
 > it still has LQ of about 37,5% after 30 seconds<br> > after 66 seconds 25%<br> > and after 138 seconds it`s still 12,5%<br><br>We already have a timeout algorithm, so that should be no rpoblem ;)</blockquote><div>
<br>yes, but i thin i want two timeouts, one to drop any routes over this link, and one to clear all information about this link<br><br>because a 30 second dead link, shouldn`t be used for routing, but if it comes up after 35 seconds, the link sensing should still have enough information to be at least as skeptic as if the link was down for 20 seconds,..</div>
<br><blockquote class="gmail_quote" style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0; margin-left: 0.80ex; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex">
Unidirectional links will not really matter because a link is only<br> announced if both the neighbor and the node itself generate a "good"<br> LQ value (exchanged by Hellos).</blockquote><div><br>unidriectinoal or not was not my point, but a dead link`s etx drops slower than an 95% loss link, because its nlq is freezed, and i dislike this,..<br>
maybe it would be a good idea to lower the nlq with every hello timeout (only if no olsr packets from this node are received)<br>the problem with this feature is, it just breaks anything, and creates loops for sure.. <br>
(i will have to investigate a bit before writing any further on this point (-;)<br></div><br><blockquote class="gmail_quote" style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0; margin-left: 0.80ex; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex">
 ><br> > a method to improve this algorithm on lowering the lq deeper on desastrous<br> > situations (this includes but is not limited to dead links) would be to use<br> > the very old part (last quarter (= last 3-4 time slots)) of the history only<br>
 > when their values are lower than the newer parts:<br> > that means oLQ would be split into an old and a new part, comparing them<br> > before deciding whether to use the old parts,..<br><br>We will have to be careful with this... </blockquote>
<div><br>with what? </div><br><blockquote class="gmail_quote" style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0; margin-left: 0.80ex; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex">
if most nodes of the network<br> just pump out bad ETX values, it will not really matter for routing</blockquote><div><br>ack </div><br><blockquote class="gmail_quote" style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0; margin-left: 0.80ex; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex">
 (only the relative differences will matter).</blockquote><div><br>this shouldn´t happen, no large jumps should occur,..<br>and it should be reliable in combination with old olsrs, because it does sequence number counting, and has no hard hello timeouts,..</div>
<br><blockquote class="gmail_quote" style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0; margin-left: 0.80ex; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex">
 > the conclusion, is an completely pessimistic link sensing, which will only<br> > generate compareable (to <= 0.5.5) lq result on perfect and/or stable links.<br> > but this behaviour was the target, and if its too pessimistic, there are some<br>
 > parameters, which (when misused) can even make it optimistic,..<br><br>Difficult to use together with old routers.</blockquote><div><br>why? <br>the resulting etx, will be stable, but lower,..<br>but it`s true routes will more likely go over old routers which tend to generate too good values, ..</div>
so it`s of course a good idea to update old routers,..<br><br>Markus<br><blockquote class="gmail_quote" style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0; margin-left: 0.80ex; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex">
 </blockquote></div><br>