<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>