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

Sa Nov 10 00:41:53 CET 2007

Hi Horst & al.

Hannes, /me, bernd, scb diskutieren ebenfalls gerade, wie die  
implementation von ETX in olsrd verbessert wird.
Just for your info.

Mehr kommentare inline.

On Nov 6, 2007, at 3:53 PM, Horst Krause wrote:

> hallo sven-ola + liste,
>
> 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...
>
> vorab, ich hab von routing-protokollen u. treibern keine ahnung.
> aber als ich mich letztes jahr, in vorbereitung von hoerst_mäders
> [fftrace] mit ihm über den ETX-mechanismus beschäftigt habe, war
> ich baff-erstaunt, wie unrealistisch ETX rechnet.
>
> 1) der ETX-algorithmus wird mit short/lowrate TC-daten gefüttert,
> 2) auch für einen eth-hop wird der etx um "1" hoch-gezählt.
jup, ein bekanntes "feature" aeh bug.

(...)
>
> besonders spassig war es, als die 1hop-away_molly-dsl mal futsch war.
> da haben dann die beiden 3-radio-hop-links ->marek u. ->bocki versucht
> sich im wackeln zu übertrumpfen, mit dem ergebnis,
> dass es zt. sekündlich wackelte.
>
> optimisten werden jetzt antworten,
> da kannst du mal sehen, wie perfekt unser protokoll routet;
> ich als kritischer pessimist sehe da eigentlich keinen sinn,
> denn mich interessiert weniger die routen-theorie, sondern die
> praktische verwendbarkeit solcher links, und die ist gegen null,

detto.
Allerdings muss man auch sagen, dass olsrd eine menge alten schrott  
code drinnen hat, der jetzt , schale fuer schale verbessert wird.

ich moechte aber eine ganz einfache praktische loesung vorschlagen,  
etwas, was wir in Wien und Graz sehr erfolgreich verwenden: einen  
kleinen "backbone" mit 5GHz osbridges. Layer 2, ... kein ETX krampf,  
die dinger gehen und ihr koennt echt viel bandbreite drueber  
bekommen. Und mein gott, es meshed halt nicht, aber ist halt wie ein  
switch. Passt auch.
In wien haben wir fast einen Ring mit 5GHz osbridges und die  
bandbreite ist ok.
*Mit einem einzigen echten uplink* ! (*)

osbridges kosten ca. 200 euro und *sie zahlen sich aus*

(*) ok, es gibt noch 2 DSL uplinks, die per tunnel angebunden sind,  
aber die machen das nicht fett.

> denn irgenwo ist auf der strecke immer grad ein routen-klappern.
>
>
> hier noch ein paar details zur strecke nach marek:
>
> mit 1kB-packets siehts schon anders aus:
> user at porta:~$ ping -R -s 1000 104.131.131.1
> PING 104.131.131.1 (104.131.131.1) 1000(1068) bytes of data.
> 1008 bytes from 104.131.131.1: icmp_seq=1 ttl=60 time=38.3 ms
> RR:     192.168.2.112   # my-schleppi-eth-out
>         104.131.10.1    # horstWRT-wifi-out
>         104.131.83.2    # molly-SO-eth-out
>         104.131.41.1    # molly-N-wifi-out
>         104.131.1.2     # müggel-OSO(yokoy_st+fw)-wifi-out
>         104.131.131.1   # marek-wifi-in
>         104.131.131.1   ... und zurück
>         104.131.1.2
>         104.131.83.1
>
> 1008 bytes from 104.131.131.1: icmp_seq=2 ttl=60 time=114 ms     
> (same route)
> 1008 bytes from 104.131.131.1: icmp_seq=3 ttl=60 time=22.9 ms    
> (same route)
> 1008 bytes from 104.131.131.1: icmp_seq=4 ttl=60 time=34.8 ms    
> (same route)
> 1008 bytes from 104.131.131.1: icmp_seq=5 ttl=60 time=24.2 ms    
> (same route)
> 1008 bytes from 104.131.131.1: icmp_seq=6 ttl=60 time=25.8 ms    
> (same route)
> 1008 bytes from 104.131.131.1: icmp_seq=7 ttl=60 time=34.1 ms    
> (same route)
> 1008 bytes from 104.131.131.1: icmp_seq=8 ttl=60 time=33.7 ms    
> (same route)
> 1008 bytes from 104.131.131.1: icmp_seq=9 ttl=60 time=24.7 ms    
> (same route)
> 1008 bytes from 104.131.131.1: icmp_seq=11 ttl=60 time=78.1 ms   
> (same route)
> 1008 bytes from 104.131.131.1: icmp_seq=12 ttl=60 time=42.4 ms   
> (same route)
>
> und jetzt mit 2kB:
> user at porta:~$ ping -R -s 2000 104.131.131.1
> PING 104.131.131.1 (104.131.131.1) 2000(2068) bytes of data.
> From 104.131.83.1 icmp_seq=4 Destination Host Unreachable
> 2008 bytes from 104.131.131.1: icmp_seq=5 ttl=60 time=104 ms
> RR:     192.168.2.112
>         104.131.10.1
>         104.131.83.2
>         104.131.41.1
>         104.131.1.2
>         104.131.131.1
>         104.131.131.1
>         104.131.1.2
>         104.131.83.1
>
> 2008 bytes from 104.131.131.1: icmp_seq=6 ttl=60 time=88.8 ms    
> (same route)
> 2008 bytes from 104.131.131.1: icmp_seq=7 ttl=60 time=88.9 ms    
> (same route)
> 2008 bytes from 104.131.131.1: icmp_seq=8 ttl=60 time=57.6 ms    
> (same route)
> 2008 bytes from 104.131.131.1: icmp_seq=9 ttl=60 time=53.9 ms    
> (same route)
> 2008 bytes from 104.131.131.1: icmp_seq=10 ttl=60 time=37.3 ms   
> (same route)
> 2008 bytes from 104.131.131.1: icmp_seq=12 ttl=60 time=81.4 ms   
> (same route)
> 2008 bytes from 104.131.131.1: icmp_seq=13 ttl=60 time=89.7 ms   
> (same route)
> 2008 bytes from 104.131.131.1: icmp_seq=14 ttl=60 time=74.7 ms   
> (same route)
> 2008 bytes from 104.131.131.1: icmp_seq=15 ttl=60 time=44.0 ms   
> (same route)
> 2008 bytes from 104.131.131.1: icmp_seq=16 ttl=60 time=90.0 ms   
> (same route)
> ...
> 2008 bytes from 104.131.131.1: icmp_seq=25 ttl=60 time=103 ms    
> (same route)
> ...
> # 2kB-packets kommen durch, wenn auch mit zt. ping > 100ms.
> # häufig sehe ich auf diesem trace auch X00ms delays und zig-sec- 
> interrups :-(
>
> zwischen der routen-wahl aufgrund kurzer tc-packets, und real- 
> life-2kB-packets
> ist also ein zeit-faktor von etwa 1:10, wenn es flüssig läuft.
>
> kann man erreichen, dass routing mit repräsentativen werten arbeitet?
> denn der unrepräsentative batmanInnen-originator-count
> generiert -imho- die gleichen probleme.

jo, wenn du den echten durchsatz misst und die leitung lahmlegst,  
dann geht das.
Alles andere muss zwangsweise schaetzung sein. Aber man koennte  
mehrere werte integrieren.
SNR, etx, ett(?), reinen packet loss (LQ), physikmodelle (em feld), etc.

(hm, was war "etc" fuer eine metrik? ;-)

oder anders gesagt: "wer misst, misst mist"

>
> als argument dagegen habe ich öfter gehört, dass dann real traffic
> unter-brochen würde, wenn mit voller last geprobt würde.
> der real-traffic wird aber auch zb. durch cron.minutly unterbrochen,
> und durch unrealistische routen zumindest gefährtet.
>
> gruss horst_104.131.10.1
> offlinehorst at web.de
>
>
>
>
>
>
> On Tue, 30 Oct 2007 20:41:56 +0100
> Sven-Ola Tücke <sven-ola at gmx.de> wrote:
>
>> N'abend Horst,
>>
>> Lust auf Grundsätzliches ?-) Mit Luftzeit (dt. für Airtime) meine  
>> ich die
>> insgesamt zur Verfügung stehende Sendezeit. In einer Sekunde  
>> können ja nur
>> eine bestimmte Bytezahl bei einem bestimmten Übertragungstempo  
>> gesendet
>> werden. Wenn 20% der Zeit bereits von Beacons + ACK-Paketen belegt  
>> sind, ist
>> es ratsam z.B. die OLSR und Batman-Pakete nicht unbedingt auf  
>> 1Mbit nochmal
>> 25% verbrauchen zu lassen. Das meine ich mit "Luftzeitbelegung".  
>> Und das
>> zeigt (hoffentlich) das Horst-Tool zukünftig an. Und darum ist der  
>> Default
>> für die Broadcast-Rate mit der Freifunk-Firmware > 1.6.0 auf 5.5 Mbit
>> eingestellt. Ausgehend von der Annahme, dass man ja immer noch  
>> 'runterdrehen
>> kann, aber die Mehrheit besser weniger "Luftzeit" verbrauchen sollte.
>>
>> Richtig ist außerdem: sowohl OLSR als auch Batman benutzen zur  
>> Zeit ETX AFAIK.
>> Die Packetverlust-Messung ist suboptimal, weil
>>
>> a) bei Batman die "Meßpakete" unrealistisch klein sind
>>
>> b) allgemein bei niedriger Sendrate gemessen wird, um eine
>>     höhere Reichweite für die Routing-Infos zu haben bzw. um
>>     weiter entfernte Stationen auch noch einzubinden.
>>
>> c) für eine realistische Messung auf der IP-Ebene die ganze
>>     Bandbreite aufgebraucht würde.
>>
>> Darauf gibt's keine generell 'richtige' Antwort. Man kann anfangen  
>> mit
>> Wifi-Treibern herumzuspielen und deren Meßwert-Daten  
>> einzukalkulieren. Der
>> Meßfehler ist jedenfalls da und spürbar.
>>
>  Da Elektra das mal in den Mund genommen hat gehe ich
>> davon aus, das unsere Batmannen das bereits wissen und eines Tages
>> realisieren. Angucken kann man sich das heute schon. Mit einem  
>> klitzekleinen
>> aber süßen Programm: "bing". Bing ermittelt die Bandbreite einer  
>> Verbindung
>> anhand von Laufzeit-Differenzen unterschiedlich großer Pings.
>>
>> P.S.: Das sich der Flattermann hin und wieder zur DOS-Attacke  
>> mauert sind mit
>> sicherheit in erster Linie Implementierungsprobleme. Sowas dauert.  
>> Zu OLSR
>> kann ich sagen: so langsam könnte es soweit sein, dass es wirklich
>> einigermaßen funktioniert. Hat ja auch 2 Jahre Vorsprung <ggg>
>>
>> Schönen Abend noch,
>> // Sven-Ola
>>
>> Am Dienstag 30 Oktober 2007 14:26:43 schrieben Sie:
>>> hallo sven-ola,
>>>
>>> definiere mir bitte mal "Luftzeit", bzw. "airtime".
>>>
>>> licht-geschwindigkeits-packet-flugzeit ist es wohl nicht.
>>>
>>> meintst du damit den anteil einzelner packet-arten/speeds an der  
>>> TX-dauer,
>>> oder div. anteile der empfangenen/decodierten_packet-arten an der  
>>> RX-zeit?
>>>
>>> RX-*sturm*, (# ich meine hier nicht RX-*taub-brüllen*)
>>> u. in folge auch ap-cpu-overload gabs in nieder-f'hain  
>>> flächendeckend
>>> vor ca. 2 wochen durch eine wildgewordene flattermouse.
>>> mein wrt war zäh wie leder, ping von läppi über eth: 1s ~ 7s ...
>>> unter noerds nennt man sowas wohl DOS-attacke, wenn gewollt.
>>>
>>> bei der gelegenheit will ich auch dich mal fragen, warum
>>> unrepräsentative udp/lowspeed-ETX-packets zur routenwahl
>>> benutz werden.
>>>
>>> und warum man diesen -imho- mainbug jetzt auch auf die batfrauen
>>> in form des 'originator-counts' als feature übernimmt.
>>>
>>> zum 'vorfühlen', was möglich ist, oder 'nachmessen' wenns klemmt
>>> sind solche *robusten* packets gold wert, weil sie die digitale
>>> geht/nicht-charakteristik etwas auf-fuzz-eln.
>>>
>>> aber als basis des routing-algorithmus kann es zu routen führen,
>>> durch die real-life-netto-payload evt. nicht durchkommt.
>>>
>>> gruss horst_104.131.10.1
>>> offlinehorst at web.de
> _______________________________________________
> Berlin mailing list
> Berlin at berlin.freifunk.net
> http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin
>

---
there's no place like 127.0.0.1

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

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