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

[Jens Nachtigall]

Am Mittwoch, 21. November 2007 08:31 schrieb Hannes Gredler:
> On Tue, Nov 20, 2007 at 11:06:20PM +0100, Jens Nachtigall wrote:
> | > irgendwelche vorschlaege um die bandbreite zu ermitteln ?
> | > bis jetzt gefaellt mir am besten ein kleines unmittelbar neben
> | > einem grossen hello zu schicken, weil plattformneutral.
> |
> | Vielleicht missverstehe ich das nur, aber olsr-Hello-Pakete wirst du
> | daf?r nicht nehmen k?nnen, weil diese (mit fester Bandbreiten-raten!)
> | gebroadcastet werden.
>
> mir schwebt vor - ein eigener message type der im wesentlichen
> einen 'padding' tlv enthaelt - d.h. einfach fuellmaterial.
> evtl. koennte man auch OAM informationen hier reinpacken
> (hostname, geopos, mian/max timer fuer diese messungen).

Das kann man natürlich machen, allerdings gehen die ETT-Pakete erstmal nur 1 
Hop weit. Dort könnte man natürlich die Infos mehrerer Nachbarn 
zusammenfassen, und jeweils wieder an den nächsten senden... 
Hört sich für mich erstmal hackisch an; bzw. 2. Schritt zu überlegen, ob man 
anstatt eines leeres Pakets was sinnvolles reinpacken kann. Die ETT-Pakete 
wird man weil unicast und in beide Richtungen auch nicht so häufig 
verschicken wollen wie die Hello-Pakete (alle 20 sek. und noch seltener). Da 
hätte man dann schon einiges an Verzögerung 
beim "Aggregieren->Nächster-Hop->Aggrerieren->usw".

>
> | Im Paper welches ett vorschl?gt, wird deshalb per unicast an jeden
> | (durch die Hello-Pakete bekannten Nachbarn) zuerst ein 137B gro?es Paket
> | geschickt, und unmittelbar darauf ein 1137B gro?es Paket, Dann misst man
> | die Zeitdifferenz zw. Ankunft des ersten und zweiten (Dummy)Pakets und
> | dann
> |
> | Bandbreite (besser Kapazit?t) des Links = 1000B / Zeitdifferenz
>
> du beziehst dich auf dieses paper ?
>
> http://research.microsoft.com/mesh/papers/multiradio.pdf
>
> im olsrd waere es auch realtiv einfach den gemessenen ETX
> in einen ETT ueberzufuehren und per TC zu announcen.

Ja, das Paper meine ich [0]. Ich hatte mir das so überlegt, ohne den internen 
Aufbau des olsrd so gut zu kennen wie Du:

1. ETX (also angenäherte Verlustrate) zu allen Nachbarn ist bekannt

2. alle x Sekunden (x > HelloInterval)  werden unicast die beiden Pakete an 
jeden nachbarn verschickt (PktPair, siehe oben). Das geschieht in beide 
Richtungen, und der Mittelwert aus beiden Bandbreiten ergibt, die 
Gesamtbandbreite des Links.

3. per TC wird statt ETX der ETT-Wert als Metrik announced, und der 
SPF-Algorithmus funktioniert auch wie bisher, nur dass nun ETT statt ETX als 
Gewicht/Metrik eines Links verwendet wird.

Das wäre sozusagen Step 1, Step 2 könnte man dann mal gucken, ob es möglich 
ist ins PktPair noch zusätzliche Infos unterzubringen, wenngleich ich dort 
fürs Fluten das Plugin-Interface besser geeignet finde.


grüße,
jens

[0] Dort ist auch eine interessante Metric "Weighted Cumulative ETT" 
beschrieben, wo nochmal intra-flow interference betrachtet wird, also wenn 
ein Paket auf Kanal 1 reinkommt, wäre es zu bevorzugen, dass es auf einem 
nicht-überlappenden Kanal geforwarded wird bzw. auf ethernet. Kann im olsrd 
aber leider nicht verwendet werden, sondern nur mit Source Routing (da nicht 
isotonisch). 
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : nicht verfügbar
Dateityp    : application/pgp-signature
Dateigröße  : 189 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.berlin.freifunk.net/pipermail/berlin/attachments/20071121/9ddc5588/attachment.pgp>