<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I tested the LC plugin from Eric Tromp quite a while ago.<div><a href="http://sourceforge.net/projects/olsr-lc/">http://sourceforge.net/projects/olsr-lc/</a></div><div>Nice features are:</div><div> - high speed cabled link takes precedence over WLAN</div><div> - high speed links (often more reliable) takes precedence over lower speed (often more lossy) links</div><div>Problems were:</div><div> - bugs in old OLSR, now I use fresh 0.6.0 (stable:-)</div><div> - lazy LC, convergence takes ~10 minutes<br><div>I decided to postpone work on it. First, we must get metric exchange right (OLSRv2, following RFC's).</div><div>Then, we should use L2 metrics, if available (data rate, RSSI), and use OLSR packet loss (ETX) as fall-back.</div><div>Within grey zone boundary, data rate / RSSI are important. Then, at lower rates, OLSR packet loss is becoming more important.</div><div>Data rate measurement is dependent on unicast trafic (user traffic?), which may be problematic.</div><div>In all cases, dampening / hysteresis is crucial.</div><div>And we have to think about triggered TC updates. </div><div>(sound like goodies under Christmas tree...)</div><div><br></div><div>Teco</div><div><br></div><div><br></div><div><br><div><div>Op 13 sep 2010, om 17:24 heeft Markus Kittenberger het volgende geschreven:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_quote">On Mon, Sep 13, 2010 at 4:15 PM, Bastian Bittorf <span dir="ltr"><<a href="mailto:bittorf@bluebottle.com">bittorf@bluebottle.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">> don't forget that all WLAN packets have a prefix which is send with<br><br></div>
but seriously: why use TC/Hellos at all?<br></blockquote><div>cause we have them anyways,.. so why not continue to use them somehow,..<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
We already have the link-speed from layer 1/2,<br>
we just have to do something, that this data is<br>
up-to-date.<br></blockquote><div><br></div><div>exactly! </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
And: the selected rate (from e.g. minstrel) already<br>
includes the probability/chance for goodput.<br>
(we dont have to measure this twice?)<br></blockquote><div><br></div><div>minstrel alone is measuring only less than once!</div><div><br></div><div>and for an olsrd with an metric based on minstrel data alone i expect unwanted heavy reroutings, as soon as links changes from "idle" to used.</div>
<div><br></div><div>so i suggest starting with an simple approach to just generate at least some periodic probing packets to every neighbour.</div><div>to get reliable bandwith results from minstrel.</div><div>and tune this later, (mostly) to save bandwidth #1</div>
<div><br></div><div>Markus</div><div><br></div><div><div><div>p.s. there will be much more work to get a bandwith metric running well with olsrd, than only measuring the "raw" bandwidth,..<br></div></div></div><div>
<br></div><div><div><div>#1 some optimisatino ideas</div><div>only send probes whene there is no other traffic (of appropriate packet size)</div><div>only test links that are/will used by olsrd routes,... </div><div>use/interpretate the broadcast packet loss, as indication to retest unicast bandwith of a link. wo we get somewhat unicast probing with dynamic-timing.</div>
</div><div><br></div><div>most of above optimisations will need integration of probing and linksensing (and olsrd broadcast packetloss), and will unfortunately be quite os-specific,..</div></div><div><br></div></div>
-- <br>Olsr-dev mailing list<br><a href="mailto:Olsr-dev@lists.olsr.org">Olsr-dev@lists.olsr.org</a><br>http://lists.olsr.org/mailman/listinfo/olsr-dev</blockquote></div><br></div></div></body></html>