[Berlin-wireless] MAPs der BerlinFunkwolke

[Sven-Ola Tuecke]

Moins,

also nach meiner Auffassung soll eine Map immer das Layer8-Meshing 
erleichtern. Und zum Angeben sind sie natuerlich auch prima.

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.

Die anderen Maps koennten mal die Info aus dem 
olsrd-nameserivce-broadcastet-geopos mit aufnehmen. Ein "Sensor-Node" im 
jeweiligen Mesh braucht's halt. Die kompletteste Info gaebe es damit immer 
auf den serverbasierten Maps und gegen ein "Nebeneinander" spricht ja wohl 
nix. Die jeweiligen Map-Addon-IPKs koennte man mal koordinieren...

My two cents,
// Sven-Ola

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