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

Markus Kittenberger (spam-protected)
Mon Sep 13 17:24:39 CEST 2010


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,..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20100913/f428f6cd/attachment.html>


More information about the Olsr-dev mailing list