[Berlin-wireless] Tempo Tempo

[Marco Tidow]

On Mon, Jun.25. 19:16 +0200, dirk wrote:
> Marco Tidow schrieb:
> > moin,
> > ansonsten, probiert ;-)

> ist dies folgende die wiedergabe des Inhaltes von dem obigen Text bzw.
> deiner ausprobierten Implementierung in Anlehung an obigen Text?

ist praxis-ergebnis;   am ende aller schönen theorie muß auch die reale
implementierung im treiber mit realen umgebungen mithalten.  man kommt
um konkretes verifizieren realer setups eh nicht herum;
den text und andere habe ich erst viel später gelesen, bißchen protokoll-
programmierungs-praxis habe ich allerdings aus anderem kontext, ist aber
einmal ~ 20 und das andere mal ~ 12 J. her ;-)

zur praxis:
gibt in dieser stadt  gegenden, in denen wird der kaffee draußen nicht kalt,
bei soviel 2.4GHz in der luft.
findet man eine config, bei der die "letzte gelegenheit, die miete pünktlich
zu überweisen, weil wochenende vor deadline, aber ohne nervigen gang
ins inet-cafe", auch dort via Freifunk nicht an technischen wifi-details
scheitert, ist man schon ganz zufrieden...

hab´s nicht so schön dokumentiert wie im wcnc-ray.pdf, aber Abb.3 trifft
meine Kritik "aus dem Bauch raus"  ggü. RTS recht gut.
im grund sind aber alle modelle, gemessen an der realität, "für´n popo".
RTS-validation? o.k. mag eine lösung sein, aber auch für die praxis?

was ist, wenn, außer meinem, noch 60 andere wifi-nets rumgeistern, 20 davon
auf dem nachbar-channel "11" (FF-berlin läuft auf 10)?

wie erwähnt, RTS/CTS arbeitet nur "cell-local".  weitere wifi-nets kommen
in theoretischen arbeiten irgendwie nie vor...


egal, jedenfalls,
minutenlange, komplette "deadlocks" sonst "eigentlich" funktionierender links
habe ich seit RTS=off jedenfalls nicht mehr erlebt.  einbrüche natürlich schon,
aber nicht, ohne daß sich konkret congestion seitens eines nachbar-netzes
 "messen" ließ.
(man kann mit broadcom-hardware im monitor-mode auch "remote" sehr gut TACK´s
 - auch auf nachbar-channels - mitplotten)

also:
"nix implementierung", habe nur mit den parametern des vorhandenen "wl.o"
hantiert.  firmware basteln ist ein fulltime-job gleich für ein ganzes team,
und dann noch für´ne ganze palette verschiedenster hardware?
an MAC-level details zu schrauben, wäre derzeit illusion, zumindest eine
nischen-lösung, denke ich.

müssen mit dem arbeiten, was uns broadcom als bin-only,  oder madwifi- etc.
-entwickler per work-in-progress als open-source liefern.
selbst damit ist der kleinste gemeinsame nenner weniger, als das was
der bin-only broadcom bereits kann :-(


> Meine Meinung zum Thema
> RTS/CTS behindert den Datenfluß (TCP insbesondere da zeitkritisch)
> zusätzlich. Das dies irgendwie über das ganze Netz flutet wie Elektra in
> dem Rundfreifunk-Interview erzählt hat konnte ich bisher noch nicht
> beobachten... (?)

hm, denke wir haben nicht die möglichkeit, einen größeren ausschnitt des
netzes komplett und "out-of-the-band" in diesen details zu monitoren,
also keine ahnung, wie elektra sowas *real* beobachten will.



> Und RTS/CTS ist bei unsymetrischen Links sehr hilfreich
> TCP-Retransmissions zu verringern, denn das (TCP)-ACK vom Empfänger geht
> nicht verloren. (Vorrausgesetzt ich setzte den Thereshold von RTS/CTS
> runter)

kapier ich noch nicht:

entweder kommen MAC-TACK´s (layer-2), wenngleich
in einer richtung meinetwegen auch langsamer/später (wg. lower bit-rate)

oder - garnicht, dann ist´s aber kein link mehr, auch kein unsymmetrischer ;-)

kommen aber welche, re-justiert der sender-IP-stack sein (TCP-)timing,
-window etc.
die "bit-ratig" schnell sendende seite verlangsamt, weil das
TCP-ACK retour lange braucht, die "bit-ratig" langsam sendende wird allein vom
eigenen MAC-layer schon lokal gebremst.
dazu brauchts kein RTS/CTS.


oder meinst du mit unsymetrischen Links, daß das *layer-3*  TCP-ACK über
eine andere node zurückkommt, wg. node-lokaler routing-decisions?

bloß, was hat das speziell mit RTS/CTS zu tun, was ja nur zwischen genau
zwei nodes
- eben eigentlich noch "unterhalb" des klassischen layer-2 (ethernet) abläuft?
(schließlich können RTS resp. CTS ebenso "verloren" gehen, wie TACKs; der
daraus folgende backoff letztlich auch TCP-retransmissions auf layer-3 auslösen,
 als "extra-gelegenheit" für packet-loss in dichten node-haufen sogar
 noch zusätzlich)

und,
hierbei stelle ich mir RTS/CTS-blocks erst recht als auslöser unnötiger
TCP-Retransmissions vor, hm?


an dieser stelle wäre die Kritik dann wohl eher an der fehlentscheidung
des routing-daemons (und ursächlich in broadcast/unicast unterschieden auf
MAC-level) festzumachen, oder?



kann aber ehrlicherweise diese konstellation in der praxis nicht wirklich
"wiedererkennen", vllt. mangels passender locations, vllt. aber auch nur,
weil ich die SOHO-bit-raten automatiken nicht für mesh-tauglich halte
und deshalb derzeit - noch mangels passenden ersatzes - ausschalte.
("meine" broadcasts müssen nicht alle in der cell hören, als wohl
 wichtigstem punkt, wovon der SOHO-kram aber ausgeht)

> En Detail werd ich wohl in Weimar bei einem Vortrag drauf eingehen.

schade, bißchen weit zum zuhören.
gibt´s was zu lesen dazu?  vllt. einen mitschnitt?

Gruß, marco