[Berlin-wireless] ETX und Metrik

[Bastian]

Hallo,

"The ETX is the number of transmissions required to successfully deliver
a packet over a wireless link at the MAC layer. The ETX of a path is the
summation of ETX of every link over the path." [1]

ETX = 1/(NQ*NLQ)

Bei ETX = 1.0 geht kein Paket verloren. Es ist ein perfekter Link aus
Sicht des Packet-Loss. Bandbreite und Latenz fließen nicht in die
ETX-Metrik ein.

Angenommen es gibt 2 Routen von A zu Z:

ETX: 3.55	A <-0.75-> B <-0.75-> Z
ETX: 3.0	A <-1.0-> B <-1.0-> C <-1.0-> Z

Auf der ersten Route müssen Pakete zwischen A und B sowie zwischen B und
Z in jeweils 1/4 der Fälle neu übertragen werden. Ein re-transmit kostet
spürbar Bandbreite und Latenz. Auf der anderen Seite kostet auch jeder
weitere Hop. Entsprechend sorgt ETX für eine sinnvolle Routing-Entscheidung.

Aber:
Fat-Pipes, also Ethernet-Links ohne Packet-Loss oder richtig gute 5GHz
Backbone Links werden nicht berücksichtigt. Nun haben aber unsere
Kirchtürme mehrere kabelverbundene Nodes.
Deswegen:
"Etx_ffeth" is an experimental and INCOMPATIBLE extension of etx_ff
(meaning it will not interoperate with etx_ff nodes).  The problem with
etx_ff, etx_float and etx_fpm is that they calculate ethernet links with
the same cost as a wireless link without packet loss (ETX 1.0) because
the encoding of etx_ff cannot encode link costs lower than 1.0. This
means OLSRd prefers a single wireless link with some loss (e.g. ETX 1.5)
over a two hop route with one ethernet link (ETX 1.0) and one perfect
wireless link (ETX 1.0) *even though* the latter path would be better! " [2]

Wir setzen die Option "mesh" (etx_ff) für Ad-Hoc Interfaces (ebenso bei
AirOS-VLAN-Konstruktionen) und "ether" (etx_ffeth) wenn OLSR auf einem
LAN Interface gesprochen wird.
Jeder Hop entscheidet selbst über das weitere Routing eines eingehenden
Pakets. Nodes im Kirchturm werden also die Kabelverbindung bevorzugen.


[1]: http://www.ece.gatech.edu/research/labs/bwn/papers/2005/j4.pdf
[2]:
http://redmine.confine-project.eu/projects/olsrd-ccninfo/repository/revisions/master/entry/README-Olsr-Extensions
[3]: http://www.olsr.org/docs/README-Link-Quality.html

Gruß
Bastian


On 06/07/2014 06:47 PM, anha4 at web.de wrote:
> Hallo,
> 
> schaut man sich einige zusammenhaengende ETX 1.0-Links an und sieht dann in den Routen nach, so haben diese Links bei
> Metrik 1  ETX 1.0
> Metrik 2  ETX 2.0
> Metrik 3  ETX 3.0
> Metrik 4  ETX 4.0
> usw. 
> Das hiesse ja, bei Metrik 2 waeren automatisch schon die Haelfte der Pakete verloren, bei Metrik 3 2/3 der Pakete weg und bei Metrik 4 75% weg. Ist das so? Das widerspricht eigentlich der praktischen Erfahrung und ist auch mathematisch kaum nachzuvollziehen. 
> Und die Frage: Bezieht der olsrd diesen Umstand mit in seinen Entscheidungsalgorithmus ein?
> Das hiesse, er waehlt lieber eine kurze Route mit schlechtem ETX der Einzellinks als eine lange mit gutem ETX der Einzellinks, denn die lange Route wird schon bei Metrik 4 z.B. mit einem "Grund-ETX" von 4.0 beaufschlagt.
> 
> Gruesse Andreas


-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 538 bytes
Beschreibung: OpenPGP digital signature
URL         : <http://lists.berlin.freifunk.net/pipermail/berlin/attachments/20140608/793a9e27/attachment.pgp>