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

Di Nov 6 15:53:58 CET 2007

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.

zb. der 3_radio-hops-trace *me_molly_yokoy_marek* (ping ~10ms)
dort sind im trace liegende ETHs (zb. 2 molly-IFs back2back)
mit ~ 0,8ms praktisch unrelevant.

pings sehen so aus:
64 bytes from 104.131.131.1: icmp_seq=1 ttl=60 time=69.1 ms
64 bytes from 104.131.131.1: icmp_seq=2 ttl=60 time=8.07 ms
64 bytes from 104.131.131.1: icmp_seq=3 ttl=60 time=14.4 ms
64 bytes from 104.131.131.1: icmp_seq=4 ttl=60 time=7.66 ms
64 bytes from 104.131.131.1: icmp_seq=5 ttl=60 time=12.0 ms
64 bytes from 104.131.131.1: icmp_seq=6 ttl=60 time=16.2 ms
64 bytes from 104.131.131.1: icmp_seq=7 ttl=60 time=10.6 ms
64 bytes from 104.131.131.1: icmp_seq=8 ttl=60 time=7.31 ms
64 bytes from 104.131.131.1: icmp_seq=9 ttl=60 time=15.4 ms
64 bytes from 104.131.131.1: icmp_seq=10 ttl=60 time=7.19 ms
# gut 30% sind ~7ms-pings, gehen nicht über die durch richt-antennen
  vorgegeben link-strecke <me ~ mollySO(-eth-)N ~ yokoy ~ marek>,
  sondern den 2hop-weg *me ~ molly-SO ~ marek= ~7ms geht, 
  der einen schlechterere/unsymetrische LQ/NLQ als der 3hop-weg hat.
  vmtl.wg. cron-minutly auf einem der im trace liegenden molly-IFs
  oder weil evt. yokoys_müggel-OSO cront/wackelt/brown/congested ist,
  dort konnte ich auch schon beobachten, dass es über "fragonard"(=NW)
  läuft, dessen antenne in die entgegengesetzte richtung zeigt,
  folglich einen deutlich schlechtere LQ/NLQ zum molly hat. 
  und dies ist noch der gute zustand, kaum delays u. keine abrisse.

(ähnliches habe ich auch schon auf dem 3-radio-hops-trace 
 *me ~ molly-SO(-eth-)-SW ~ zwingli-NO(-eth-)-SW ~ bocki* beobachtet,
 dass es nicht bei molly-SO rein (-eth-) zum molly-SW wieder raus geht,
 wie die radio-links durch richt-antennen- mit besseren LQ/NLQ vorgegebene wäre,
 sondern den *falschen_weg* molly-SO_store+fw (schlechtere LQ/NLQ), der
 dem routing-algarithmos entweder wegen 1_hop_kürzer attraktiver erscheint,
 oder wg. cron-minutly die einzige, aber schlechtere route ist.
 routen-flappen und minutenlange abrisse sind die folge.)

so oder ähnlich mag es auch auf der zwingli abgehen, denn dort kann man
noch häufiger beobachten, dass es nicht zum geplanten  zwingli-NO rein-geht,
sondern bei zwingli-SO, dessen antenne in eine ganz andere richtung kuckt.
aber die zwingli ist noch mal ein fall für sich, wo ich zt. nicht mal
mehr ein web-IF öffnen kann...

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,
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.

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-wireless] ETX(+bat) unrealistisch, war:Re: airtime? *robuste_packets*?

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