[Olsr-dev] mac80211 / link-bandwith from userland forcostcalculation / plugin

[Teco Boot]

I tested the LC plugin from Eric Tromp quite a while ago.
http://sourceforge.net/projects/olsr-lc/
Nice features are:
 - high speed cabled link takes precedence over WLAN
 - high speed links  (often more reliable) takes precedence over lower speed (often more lossy) links
Problems were:
 - bugs in old OLSR, now I use fresh 0.6.0 (stable:-)
 - lazy LC, convergence takes ~10 minutes
I decided to postpone work on it. First, we must get metric exchange right (OLSRv2, following RFC's).
Then, we should use L2 metrics, if available (data rate, RSSI), and use OLSR packet loss (ETX) as fall-back.
Within grey zone boundary, data rate / RSSI are important. Then, at lower rates, OLSR packet loss is becoming more important.
Data rate measurement is dependent on unicast trafic (user traffic?), which may be problematic.
In all cases, dampening / hysteresis is crucial.
And we have to think about triggered TC updates. 
(sound like goodies under Christmas tree...)

Teco



Op 13 sep 2010, om 17:24 heeft Markus Kittenberger het volgende geschreven:

> On Mon, Sep 13, 2010 at 4:15 PM, Bastian Bittorf <(spam-protected)> wrote:
> > don't forget that all WLAN packets have a prefix which is send with
> 
> but seriously: why use TC/Hellos at all?
> cause we have them anyways,.. so why not continue to use them somehow,..
> We already have the link-speed from layer 1/2,
> we just have to do something, that this data is
> up-to-date.
> 
> exactly!  
> 
> And: the selected rate (from e.g. minstrel) already
> includes the probability/chance for goodput.
> (we dont have to measure this twice?)
> 
> minstrel alone is measuring only less than once!
> 
> 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.
> 
> so i suggest starting with an simple approach to just generate at least some periodic probing packets to every neighbour.
> to get reliable bandwith results from minstrel.
> and tune this later, (mostly) to save bandwidth #1
> 
> Markus
> 
> p.s. there will be much more work to get a bandwith metric running well with olsrd, than only measuring the "raw" bandwidth,..
> 
> #1 some optimisatino ideas
> only send probes whene there is no other traffic (of appropriate packet size)
> only test links that are/will used by olsrd routes,... 
> use/interpretate the broadcast packet loss, as indication to retest unicast bandwith of a link. wo we get somewhat unicast probing with dynamic-timing.
> 
> most of above optimisations will need integration of probing and linksensing (and olsrd broadcast packetloss), and will unfortunately be quite os-specific,..
> 
> -- 
> Olsr-dev mailing list
> (spam-protected)
> http://lists.olsr.org/mailman/listinfo/olsr-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20100913/f294c2ee/attachment.html>