[Berlin-wireless] MAPs der BerlinFunkwolke

[Horst Krause]

On Mon, 8 Oct 2007 10:47:03 +0200
"Sven-Ola Tuecke" <sven-ola at gmx.de> wrote:

hallo sven-ola und liste,

> also nach meiner Auffassung soll eine Map immer das Layer8-Meshing 
> erleichtern.

jau, also den usern
- social_engineering, community-building ermöglichen, dh.
- nachbarn zu finden, links auf zu bauen, und
- störungen und engpässe zu beseitigen.

> Die minimal-Karte in der Firmware werde ich so erhalten wie sie ist und 
> weder groszartig aufbohren noch entfernen. Die ist naemlich prima, wenn man 
> in "Hintertulusien" sitzt und gerade mal ein temporaeres AdHocMesh aufmacht 
> und sich um sonst nix kuemmern will.

1) der 'ernstfall' für den einsatz deiner "dezentralen"_Karte tritt nicht
erst in "Hintertulusien" ein, sondern der daily_worst_case sind alle
die wlan-interessierten/-anfängern/-inseln, die zb. im "Hinterhof" noch
kein luftnetz sehen, und kein i-net, also auch kein maps.google haben.
die brauchen einfache tools, die ihnen vor/beim ersten wackel-connect sagen,
- was um sie herum '3_hops_away'-topologisch los ist, und
- wie sie zu nachbarn per sneaker-net / email kontakt aufnehmen können,
  um zu entscheiden, bei/mit wem/was es möglich/nötig ist, und
- welche antenne sie wo aufbauen und wie ausrichten können,
  um zu dem günstigsten nachbarn stabil zu linken,
  hinter dem es auch eine performante route zum i-net-gateway
  = erst dann gibts maps.google ;-)
(zb. letzten Fr. inner c-base-main-hall mit lappi-eth-wrt, aber da -imho-
 dein olsr-tunnel nicht da war, kein olsr->i-net-connect = *white_Karte*)
die recommended-firmware sollte diese funktionen/infos kompakt u laien-lesbar
enthalten und auch auf schmalen "Hinter-tulusien/-hof"-recourcen laufen.
"am anfang muss immer einer alleine anfangen"; und umgekehrt,
 wenn mein uplink wegbricht, bleibt mein verwaister node .
rescue-tools und ne minimal-map/topo brauche ich genau dann,
wenn ich die long-versionen nicht mehr erreichen kann!

2) alle, die neben ihrer dsl + rechner-farm sitzen, und mit pimmel-antenne
auf anhieb 30 olsr-nodes 'sehen', sind in der völlig anderen situation, auf die
prima laufende *zentrale* struktur zugreifen zu können, häufig sind sie es selber.
dort besteht eher die gefahr, dass die coder versuchen, die störende wirk-
lichkeit dadurch zu dominieren, dass sie in deren kisten 'virtualisiert'
und damit 'positiviert' wird, dh. die bodenhaftung verliert.

3) ein anderer fall ist forschung / netz-entwicklung / entstörung, dort will man
viele infos, besonders die *schlechten*, *unexpected*, *inkonsistenten*, auch zb.
des ungeliebten_bösen_analogen_environment von layer'null' an aufwärts,
immer nach dem motto:
"was machte es noch, bevor es dann nichts mehr machte?"
zb.: power-supply-brown-outs , hickups, glitches, delays, oder
wieviel NOISE_ist_auf_jedem_channel oder welche IF-CONGESTION besteht?

4) PR/media/art/werbe/polit/vereins/.com-fraktionen, also layer-9~10-overheads,
kommen gut ohne wirklichkeit aus, die stört nur beim erschaffen von einzigartige/
neue/bunte/wunderbare präsidation-realitäten fürs begeistert staunende publikum.
die würden sich ohne funknetz aus eigenem schwung noch lange um sich selbst drehen,
bzw. ihre seilschaften schaffen, das kann mal ein soziaologe versuchen zu mappen.
  
> ... gegen ein "Nebeneinander" spricht ja wohl nix.

ich hab kritisiert, dass es so aussieht, als wenn die einzelnen maps, zb.
in f'hain nur noch die nodes/links je eines von verschiedenen *imperien*
darstellen, obwohl tatsächlich links zwischen diesen clustern bestehen.
die diversifizierung der funknetze in mehrere kanäle/cells/insel/orte
ist ohnehin im gange (zb. wird der channel:10-mythos endlich aufgelöst).
deshalb bitte ich, map-plugin-funktionen und display-layer anzubieten,
die dazwischen liegende gateways/bridges/tunnel ermitteln und darstellen,
dh. mehr als die bisherigen .draw-daten transportieren.

> Die jeweiligen Map-Addon-IPKs koennte man mal koordinieren...

die node-data-bases bitte auch, und für offline-betrieb mobil verfügbar.
und step-by-step-DAU-howtos (bin selber ein 'depp')
und eine 'bitte_in_die_map_eintragen'-aktion.

"wenn wünschen helfen würde", dann
- eine map-engine,
- die mehrere map-syteme als unterlage auszuwählen ermöglicht,
- über die man dann ein grosses spectrum von funktions-layern legen kann.
  gaaanz oben a.d. funktions-wunschliste:
   hoerst_mäders [fftrace]-weihnachts-edition,
   gerne auch als zukünftiges *bat-trace*.
  
gruss horst_104.131.10.1
offlinehorst at web.de



> ----- Original Message ----- 
> From: "Horst Krause" <offlinehorst at web.de>
> To: "wirelesslan in Berlin" <berlin at berlin.freifunk.net>
> Sent: Monday, October 08, 2007 12:57 AM
> Subject: [Berlin-wireless] MAPs der BerlinFunkwolke
> 
> 
> hallo mapper und liste,
> 
> wie ich erfahren habe, soll am Mi (?) inner c-base ein treffen der
> entwickler der div. maps stattfinden, u.a. (i. alphabet. folge):
> 
> - alina's betaMap,  http://map-beta.berlin.freifunk.net/
> 
> - gerald's ffMap,   http://layereight.de/freifunkmap.php
> 
> - sven-ola's Karte, http://213.61.66.94/cgi-bin-map.html
> 
> - thoma's freimap,  http://freimap.berlios.de/
> 
> hoffentlich, ist dabei soviel kooperation möglich, dass es wieder
> EINE map der berlinFunkwolke gibt, und nicht, wie zz.
> verschiedene maps, die je eine andere netz-insel darstellen,
> die anscheinend weder informatisch, noch organisatorisch
> zusammenhängen.
> 
> bei dieser gelegenheit möchte ich die frage stellen,
> was eine map darstellen soll?
> - eine PR-hype der tollen berliner hauptstadt-community,
> - eine präsentation des upcomming "batman"-routing-protocol, oder
> - ein tool zum bebuggen, analysieren und open-network-entwickeln
>   des tatsächlichen status der cells/bridges/nodes/links.
> 
> anlass für diese kritische frage ist zb. die erfahrung mit der
> *alten* map, wo an jedem link der ETX (in %) ablesbar war.
> leider war dieser etx-wert nur von geringem praktischem nutzen,
> (so bestechend das konzept ist, alles mit EINER zahl zu bewerten)
> weil die kurzen count-packets u. deren data-rates, aus denen der
> etx-wert ermittelt wurde,
> kaum übertragbar waren auf längere payload-packets/-rates, die leichter
> *verloren_gehen*; angezeigte %-werte also meist zu optimistisch waren.
> mal ganz abgesehen davon, dass der algorithmos für multi-hop-routen-
> entscheidung -imho- so sinnvoll / präzise war,
> wie wenn man nicht nur *Äpfel + Birnen* addiert,
> sondern wenn man eine summe aus *Apfelbäumen + Birnen* bildet.
> mit dem neuen batman-originator-count wird bestimmt alles besser!
> 
> ein zweites bedenken ist (wenn ich das richtig verstanden habe),
> dass "batman" nur_einseitige links verwirft, und alina sich in
> ihrer map-engine dieser policy anschliessen will. dies mag fürs
> routing in einem funktionablen net die richtige entscheidung sein.
> 
> wenn man aber von einer aufbau- / entwicklungs-situation ausgeht,
> und sinngemäss gilt dies auch im falle von störungen / ausfällen,
> dann hat man nur_einseitigen links, und genau in solchen fällen
> möchte ich bitte infos/details aus der map ablesen können.
> ;-) wenns der virtualisierungs-server denn her gibt ;-)
> 
>   denn, und hier wieder das wort am sonntag:
>     "routing-protokolle kommen und gehen,
>      nur das wackeln der link-strecken,
>      das bleibt bestehen"
> 
> 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 
> 
> _______________________________________________
> Berlin mailing list
> Berlin at berlin.freifunk.net
> http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin