[Berlin-wireless] Re2: bei ahdemo kein "Listen before Sending" (cca)

So Dez 9 14:00:39 CET 2007

hallo daniel, jens u. liste

erstmal thanks fürs nachgraben und mit-wundern.

@daniel
sorry, wenn ich da durch demonstratives infrage-stellen
von seit langem festgeklopftem und angeblich selbst-verständlichem
auf deinen nerven herumgetrampelt habe.

aber ich lass es mir nicht mehr verbieten, und mag es mir auch selbst
nicht versagen, immer wieder drauf rum zu reiten, und zu fragen, warum:
- geht es meist nicht mit mehr als 1MB/s
- geht es kaum weiter als 3 radio-hops
- wackelt es dermassen, oder es gar nicht.
- gehen zentrale netz-distributions-strukturen, von denen
  viele leute abhängig sind, häufig höchst mangelhaft/nicht, wie
  - dienste + deren announcements
  - inet-uplinks
  - backbones,
  - (kirch-)türme
- warum sind die maper nicht in der lage dieses chaos
  - objektiv darzustellen
  - hints für *pimp_your_link* zu geben.
- warum wird dies in der aussen-darstellung beschwiegen, und
  seit jahren mit freyfake-werbe-lügen übertüncht.
- warum wird statt dessen eine beschäftigungs-therapie betrieben, die
  - einerseits die coder mit hektischstem releasen, und
  - die user mit unablässigem inst./comp./conf.-foo
  in atem hält.

vielleicht, weil diese frage die strategien zu sehr in frage stellt, wie:
- dominance by code/protocoll
- dominance by publicity
- dominance by "mach es doch besser"-abwehr

tatsache ist -imho-, dass wir mit genau diesen strategien den für
viele leute (von allen seiten) als erschöpfend unzufrieden-stellend
empfundenen gegenwärtigen status gekommen sind, wir haben ihn selber
mit intensivster tätigkeit, grösst-möglicher specs-konformität,
aber auch äusserster verdrängung der traurigen ergebnisse,
selbst hergestellt.

als ich mal vor ein paar jahren als querschläger in diese scene
gestolpert bin, hiess eis noch:
 "eine freie welt durch freie software" und
 " alle daten müssen maschinen-lesbar sein"

ich dagegen sage, und ich sehe dabei durchaus meine eigene
bedürftigkeit, betroffenheit und auch mängel:

 der wesentliche punkt ist die kommunikation zwischen menschen.
 maschinen, formate, protokolle, ect. sind mittel zum zweck.

wenn man technik nicht als gemeinsames 'spiel-zeug/platz' sieht,
sondern net-tech benutzt, um sich von andern abzugrenzen,
wird sie vom werkzeug zur waffe.

auch zb. 802.11 wird eines tages fallen.
 "die wahrheiten von heute sind die irrtümer von morgen".

 "procolls, maps, firmwares kommen und gehen,
  nur das wackeln der linkstrecken,
  das bleibt bestehen."

vielleicht würde es mehr helfen, die kisten mal aus zu machen,
und das mache ich jetzt, getreu dem motto:

 heute bleibt die kiste kalt,
 horst geht in den plänterwald. 

gruss horst_104.131.10.1
offlinehorst at web.de

On Sat, 08 Dec 2007 12:36:18 +0100
Horst Krause <offlinehorst at web.de> wrote:

> hallo jens,
> 
> thanks.4.infos.2
> 
> > sogenannten "energy detection threshold" (EDT, in der regel nicht 
> > einstellbar, vielleicht bei OpenHAL?) überschreiten. EDT ist per 
> > default -76dBm.
> 
> jau, was wäre, wenn die luft dauernd mit mehr *energy* belegt wäre?
> 
> > dann wird das medium als belegt angenommen und nicht gesendet,
> > stattdess geht der gewillte Sender in den backoff.
> 
> backoff, backoff, backoff...
> wahrscheinlich dauernd, na toll!
> 
> sowas mag aufm labortisch mit wenigen nodes und silent_environment
> prima funktioniert haben, hat aber mit der heutigen urban_situation
> praktisch nix mehr gemein.
> mal ganz abgesehen davon, dass es -imho- überhaupt nicht
> phy.-rate-sensitiv ist.
> 
> jedenfalls haben wir jetzt ein kriterium, dass ich mal analog
> zu 'air-time/luft-zeit nun'"AIR-PRESSURE/LUFT-DRUCK" nennen will.
> 
> das lässt sich im rahmen des funk-wetter-projekt
> auch viel besser memorieren :-))
> 
> jens, vielleicht kannst du mir auch noch die anderen wahlmöglichkeiten
> des "radio measurement" erklären in
> [wl -h].. (attachment vorige mail)
> zeile5: rm_req  Request a radio measurement of type basic, cca, or rpi
> 
> was ist denn BASIC und RPI, und mit was features überraschen die uns?
> 
> gruss horst_104.131.10.1
> offlinehorst at web.de
> 
> 
> On Sat, 8 Dec 2007 09:06:21 +0100
> Jens Nachtigall <nachtigall at web.de> wrote:
> 
> > Am Freitag, 7. Dezember 2007 23:02 schrieb Horst Krause:
> > > hallo,
> > >
> > > gibt mir bitte mal jemand einen meiner dau-kompetenz
> > > angemessenen einstiegs-infos für "cca"
> > 
> > Hallo Horst,
> > 
> > es gibt physical CCA und virtual CCA, beides passiert im PHY layer. 
> > 
> > Beim physical CCA misst die Karte, ob die empfangenen mW einen
> > sogenannten "energy detection threshold" (EDT, in der regel nicht 
> > einstellbar, vielleicht bei OpenHAL?) überschreiten. EDT ist per 
> > default -76dBm. Wenn ein Signal solcher Stärke erkannt wird, dann wird das 
> > medium als belegt angenommen und nicht gesendet, stattdess geht der gewillte 
> > Sender in den backoff.
> > 
> > Beim virtual CCA läuft das darüber, dass der PHY layer dem MAC Bescheid sagt, 
> > dass das das Medium grade busy ist, ohne dass da konkret gemessen wird. Woher 
> > weiß er das? Zuvor hat er ein Paket empfangen (RTS, CTS, oder normales 
> > data-packet), in dem das NAV-feld gesetzt war (Network allocation vector). Da 
> > steht im Prinzip drin, wieviele usec der andere Knoten nun noch senden wird, 
> > und der eigene Knoten weiß dann, wann es sich lohnt, dass nächste Mal 
> > reinzuhorchen.
> > 
> > So in etwa stehts in 
> > http://www.amazon.de/802-11-Wireless-Networks-Definitive-Guide/dp/0596100523/ref=sr_1_3?ie=UTF8&s=books-intl-de&qid=1197101051&sr=8-3
> > imho das beste buch zu 802.11 (wenngleich wenig mesh-lastig)
> > 
> > grüße,
> > jens
> > 
> _______________________________________________
> Berlin mailing list
> Berlin at berlin.freifunk.net
> http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin