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

[Horst Krause]

hallo jens + liste,

zum thema ETT, u.a.:

> ...indem man hintereinander 
> zuerst 1 kleines und dann 1 großes Paket unicast zu jedem Nachbarn schickt 
> (PacketPair), und die Zeitdifferenz misst..

interessantes konzept, und -imho- ein kiss-chen!
wenn du schon was lauf-fähiges hast, talk doch mal mit sven-ola,
damit es user-friendly aufn wrt gebügelt werden kann.

wenn ich mal einen kürzlich von keks gemachten vorschlag weitergeben darf:
 eine ping/mtr/netperf-artige funktion, die verbindungen zu nachbar-nodes
 mit ansteigenden packet-längen checkt, und darüber statistiken schreibt.
 so dass man die wirkung der änderungen im trace in einem
 vermutlich *treppen-artigen* respond-diagrammen sehen kann.
 gern auch als histories :-))

pdf ist für mich hard-stuff, heb ich mir für die nächste piss-wetter-phase auf.
aber paper-addicted alex's wird sich sicher drum reissen...

mehr faktoren ins routing ein zu beziehen, als den für real-payload
un-repräsentativen short/lowrate-packets-count 
ist ein guter ansatz.

ETX ist so schlimm, als wenn man beim obst-kauf nicht nur äpfel + birnen addiert,
sondern statt dessen apfel-kitschen u. birnbaum-stamm-abschnitte in eine tüte packt,
und sich nachher wundert, warum man damit keinen kompott kochen kann.

absehbares problem: wenn du es den node-admins überlässt an den schrauben zu drehen,
wird es wie gehabt, jede menge proprietär-fantastische erfolge geben, aber -imho-
nicht mehr durchsatz/zuverlässigkeit bei zb. *reallife payload 3-hops-routen*.

> ..in einem größtenteils statischen Netz..

"grösstenteils statisch" ist non-congested-ETH, radio ist es definitiv NICHT, s.u.

> ..reicht es wahrscheinlich aber auch aus, jede Minute ein PacketPair zu schicken,
> weil sich die link-bandbreite zum nachbarn nicht so oft verändert.

das sind eigentlich 3 themen mit evt. nano-sec-skalierung:
- die physik der ausbreitungs-bedingungen auf einer potentiellen links-strecke.
- die im node o. netz selbst gemachten einflüsse, wie
  - TX-power, modulations-bandbreite, overload, *airtime*-congestione, ect.,
  - gegenseitige stroboskopische einflüsse von mehreren IFs auf einem mast,
  - die einflüsse durch non-our-net-neighbors o.a. tech-noise.
- die reaktion von IFs und protokollen der link-partner auf diese bedingungen.
ja richtig, hier kann man ursache u. wirkung nicht sauber trennen, sowas
gerät leicht ins 'chaotische' schwingen/fluktuieren.

es gibt relativ stabile links in ruhiger rand/land-lage,
andererseits fluktuiert es in unserem urbanen-mesh-network-environment mehr, als 
wir messen und anzeigen können, und deshalb wahr-nehmen/haben können/wollen:

das (nutz-)signal ist auf seinem weg einer menge von veränderlichen einflüssen
ausgesetzt, zb. (evt. auch zeitlich/örtlich beweglichen) dämpfungen und
mehrwege-empfang durch refexionen, und ergo (evt. wandernde) *funklöcher*.
auf das (gewollte!) signal hat man noch relativ grossen einfluss, durch sinnvolle
topologie/link-planung und die wahl von antennen-standorte/gain/polarisation.
(das selbst dies zu wenig gemacht wird, ist hier nicht das thema) 

der noise (physikalisch ebenfalls leistung in dBm) fluktuiert noch stärker.
er besteht aus mehreren komponeten und ist auf niederdeutsch gesagt
dass was "das andere" o. "die anderen" machen, und die sind viele.
was *stört*, ist letztlich das unbeeinflussbare, ungewollte, u. fremde.
im urbanen environment sind dies im wesentlichen die anthropogenen
störqellen, die dauernd oder temporär herum-'britzeln' und -'prasseln'.
ein dBm-mittelwert sagt wenig über die spectrale/zeitliche/räumliche
häufigkeit, verteilung u. wirkung dieser hum-, peak- u. spike-events.
im digitalen nerdiversum werden viele der 'analogen' stör-belastungen
gar nicht angezeigt, zb. weil sie nicht protokoll-konform sind, oder
weil die coder sie im "average" versenkt haben, oder die werbe-fritzen
sowas nicht in der config., auf 'm waschzettel oder gar karton sehen wollen.
die graduelle verschlechterung eines link, bzw. das vergrauen "brown-out"
von vorher guten links wird oft nicht bemerkt, oder gern ausgeblendet,
da die digitaliker in ihrem I/0-horizont nur mangelhafte vorstellung
und begrifflichkeit dieser phänomene haben.

wenn es dann "zäh" wird oder "einfriert", oder rum-"zickt",
werden solche unerklärlichen episoden schnell verdrängt,
oder mit "funkwetter"-folklore erklärt und
mit mythischen *lösungen* behandelt.

  "routing-protokolle kommen und gehen
   nur das wackeln der funk-strecken
   das bleibt bestehen".

soweit das wort am sonntag

gruss horst_104.131.10.1
offlinehorst at web.de  



On Fri, 16 Nov 2007 10:17:02 +0100
Jens Nachtigall <nachtigall at web.de> wrote:

> Hallo,
> 
> > thanks für die *airtime*-infos.
> >
> > > Besser wird es möglicherweise mit dem ETT-Ansatz.
> > > Expected-Transmission-Time ist ein anderer Algorithmus als ETX - der
> > > genau diese Senderate
> > > berücksichtigen könnte.
> >
> > zu ETT  hab ich mich noch nicht schlau gemacht, ich vermute
> > aber im ansatz die gleichen "expected"-mängel...
> 
> ETT ist nichts anderes als ETX geteilt durch die Bandbreite des Links, deshalb 
> auch Expected Transmission Time. D.h. bei einem 100Mbit ethernet link, hast 
> Du natürlich eine viel kleinere ETT, d.h. bessere Metrik, als bei einen 1Mbit 
> link. Annähernd berechnen kann man die Bandbreite, indem man hintereinander 
> zuerst 1 kleines und dann 1 großes Paket unicast zu jedem Nachbarn schickt 
> (PacketPair), und die Zeitdifferenz misst, d.h. wie lange brauchte das große 
> Paket. Unicast kostet natürlich selbst "Bandbreite", in einem größtenteils 
> statischen Netz aber reicht es wahrscheinlich aber auch aus, jede Minute ein 
> PacketPair zu schicken, weil sich die link-bandbreite zum nachbarn nicht so 
> oft verändert.
> 
> Interessant finde ich MIC, welches auch intra- und inter-flow interference 
> betrachtet und ETT um diese Eigenschaften erweitert. 
> http://www.acm.org/src/subpages/gf_entries_06/YalingYang_src_gf06.pdf
> 
> Ich schreibe da grade meine Abschlussarbeit drüber, und will MIC und ETT auch 
> über den olsrd implementieren und dann mit ETX und HopCount vergleichen. 
> Vielleicht kommt was bei raus, was man nutzen kann, vielleicht wirds aber 
> auch nur hackisch, wie immer bei uni-arbeiten. ist zumindest aber ein anfang.
> 
> @bruno, auch von mir ein verspätetes welcome back
> 
> gruß,
> jens
>