[Berlin-wireless] ETX(+bat) unrealistisch, war:Re: airtime? *robuste_packets*?

[Sven-Ola Tücke]

Moins,

hier mein Senf zum Thema. Solange der OLSRD auf Layer3 hockt und einen opaken 
Layer2-Transport verwendet wird das nix. Ja - man kann evnt. noch tricksen 
und versuchen, ein Stueck der Realitaet zu erhaschen indem man 
Paketlaufzeiten ermittelt. Eine andere moegliche Messgroesze auf dieser Ebene 
waere noch die Zuverlaessigkeit (aka. wieviele Monate existiert der Link 
schon, wieviel erfolgreiche TCP-Verbindungen ohne Abbruch) - eine Messgroesse 
die z.B. bei der HNA0/0-Berechnung etwas bringen koennte.

Jedenfalls sind zwischen Real-Live und OLSRD zuviele Zwischenschichten, die 
Messfehler verursachen - ganz egal welches Betriebssystem:

* Interrupt-Latenz-Zeiten und Systemlast
* Unterschiedliche Uebertragungsmodi / Tempo
* Moegliches Trafficshaping (z.B. bevorzugt kleine Pakete)
* Sende-Wiederholungen, ACKs, FEC

Was den OLSRD aber interessant macht, ist die Moeglichkeit, es auf vielen 
verschiedenen Betriebssystemen und Transportschichten laufen zu lassen. Es 
funktioniert ganz gut - auch wenn beispielsweise Mesh-Loesungen die direkt in 
einen bestimmten WLAN-Treiber oder WLAN-Chipsatz eingegossen sind 
moeglicherweise effizienter sind. Bei der Paket-Loss-Messung verlassen wir 
uns sogar bereits auf eine weit verbreitete Layer2-Eigenschaft: Bei 
Broadcasts gibts vielfach kein Handshake - weswegen ueberhaupt Paketverluste 
messbar sind.

Mein Vorschlag waere, mit einem Plugin-Konzept Layer2-Information einspeisbar 
zu machen. Wenn die Info da ist, kann man sie einrechnen bzw. dem Netz 
mitteilen. Zwei Beispiele: In den MAC80211 die Info aus der Raten-Kontrolle 
ziehen und in die Linkmetrik-Berechnung einfliessen lassen. Oder im 
PPPoE-Treiber die ermlttelte Leitungsqualitaet uebermitteln. Dafuer braucht 
man eine Schnittstelle und eine Messgroesze fuer die "richtige" Relation 
zum "universalen" Paketloss/ETX. Beide Beispiele haben immer noch eine 
gewisse Abstraktion gegen die Hardware, will heissen: man macht es nicht von 
einer ganz bestimmten Hardware abhaengig (einem bestimmten Modem, eine 
bestimmte WLAN-Karte). Und man waere nicht generell nicht davon abhaengig, 
das die Transportschicht ueberhaupt Mess-Daten ermitteln kann.

Oder ein anderes Beispiel. Auf den WRTs haben wir einen recht undurchsichtigen 
WLAN-Treiber. Aber einen Monitor-Mode. Ein kleiner Daemon koennte also das 
prism0-Device abfragen und evnt. staendig folgendes fuer bestimmte 
Gegenstationen ermitteln (so wie das Horst-Tool auch):

* Empfangs-Staerke (Noisewert==Bloedsinn auf'm WRT)
* ACK-Time bzw. ACK-Verlust bei Unicast

Der Demon muss diese Info irgendwie in den OLSRD hineinbekommen. OK - man 
koennte LinkQualitymult's in die olsrd.conf schreiben und neu starten. Fuer 
mich riecht das nach Plugin.

Bleibt die Frage nach der Rechenvorschrift. Es gab ja schon echte 
ETX-Glaubenskriege zwischen der 1+1 und der 1 * 1-Fraktion (oder anders: Mit 
Hopzahl oder ohne). Im Moment fahren wir _mit_ Hopzahl (also Plus wie im 
ursprueglichen ETX-Vorschlag). Der Punkt hier: man kann das nicht alle 
Naselang aendern. Es muss naemlich Einigkeit bei allen installierten 
Instanzen geben, sonst berechnen verschiedene Stationen was unterschiedliches 
und es gibt Kreise bzw. Pingpongs. Ein Nachteil von Link-State. Eine neue 
Rechnenvorschrift in Form von Implementation zu verbreiteten dauert aber 
Monate wenn nicht noch laenger. Moglicherweise kann man auch die 
Rechenvorschrift auch innerhalb des Protokolls mitsenden (nur so als Idee - 
beanspruche hiermit Pior-Art-Schutz falls keine Prior-Prior-Art).

// Sven-Ola

Am Dienstag 20 November 2007 19:30:58 schrieb Hannes Gredler:
> On Tue, Nov 20, 2007 at 01:54:50PM +0100, Daniel Nitzpon wrote:
> | Hannes Gredler schrieb:
> | > On Tue, Nov 20, 2007 at 02:18:54AM +0100, Daniel Nitzpon wrote:
> | > | was ist denn so verkehrt an dem konzept ett = etx / bandbreite?
> | > | bisher hab ich in diesem thread noch nichts gelesen, was dar?ber
> | > | hinausweist oder dagegenspricht oder hab ich da was verpasst?
> | >
> | > es gibt werte die noch drueberhinaus interessant sein koennen,
> | > wie z.b. signal/noise ratio - das heisst es wird wohl auf einen
> | > zusammengesetzen metrik hinauslaufen.
> |
> | vielleicht k?nnten sie das, aber spontan w?rde ich sagen, sig/noise ist
> | eine der ursachen f?r die wirkung, die sich in bandbreite und packetloss
> | niederschl?gt und es ist effektiver, einfach die wirkung zu messen als
> | sich ein system zu ?berlegen, was diese wirkung aus grob gesch?tzten
> | parametern zusammenr?t.
>
> irgendwelche vorschlaege um die bandbreite zu ermitteln ?
> bis jetzt gefaellt mir am besten ein kleines unmittelbar neben
> einem grossen hello zu schicken, weil plattformneutral.
>
> am einfachsten waere es vermutlich (unter linux) die
> wireless extensions auszulesen. bin unsicher wie das auf anderen
> OSen geht (freebsd/openbsd/win32)
>
> /hannes
> _______________________________________________
> Berlin mailing list
> Berlin at berlin.freifunk.net
> http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin