Die Ideen gehen im Grundsatz ja in die gleiche Richtung nur ich denke wir haben keine lange Planungsphase.
Wir sollten uns lieber auf zwei Firmwares einstellen und wenn dadurch nur das Grundrauschen um 50% sinkt haben wir doch schon ein großes Ziel erreicht. Sei es mit der 2. FW so wie es ist: Das bauen stellt sich ja nicht als Kunst raus, dass würden wir von hier ja übernehmen.
Könnten wir dem Autoupdater denn nach den Koordinaten das Update welches er nehmen soll beibringen?
Es kann momentan nicht der Stand sein, dass man immer wieder bjo bitten muss was an den Kisten zu machen oder einfach mal eben nachts um 3 auf 4 GWS alles neuzustarten.
Es mag zwar nicht die sinnvollste Variante sein, aber es hilft uns nur!
Am 28. Juli 2015 02:41:10 MESZ, schrieb Eike Baran eike.baran@uni-oldenburg.de:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Also als schnelle sofort Maßnahme würde ich vorschlagen das wir eine layer 2 Trennung auf Gateway ebene vollziehen das sollten den Management traffic signifikant verringern das dieser überproportional steigt.
Grundsätzlich geht das vermutlich in die richtige Richtung, denke ich, ABER: ich bin mir nicht so ganz sicher, ob das eine "Sofortmaßnahme" sein kann, denn der Ansatz unterscheidet sich doch stark von dem, was wir momentan fahren und auf x Maschinen eingerichtet haben. Und eine Trennung auf dem Gateway würde ja auch bedeuten, dass dieses Gateway zeitgleich in mehreren Batman-Meshes hängen müsste und zwischen diesen routet, oder? Wir müssten da wohl erstmal Know-How checken.
Eine unproblematische Sofortmaßnahme wäre tatsächlich die - von mir auch nicht dauerhaft präferierte - Lösung über eine zweite Siteconf. Da in so (voll-)vermaschten Netzen Overhead vermutlich mehr als linear steigt, sollte eine halbierung erstmal merklich Luft bringen.
Eine zweite Firmware bzw. siteconf fände ich auch keine schöne Lösung. Mein vorschlag wäre folgender. Wir setzen einen Punkte in Form von geokoordinaten und lassen die Router mit Hilfe von orthodrom algerytmen ihre nächst zugehörige hood berechnen. Das ist eine schnell und sauber um setzbare Möglichkeit.
Sehe ich ähnlich, nur würde ich deinen Orthodrom-Schwachfug da streichen und einfach Geokoordinaten verwenden. In einer Config werden einfach die Koordinaten der Zentren der Hoods gespeichert und dann mit Pythagoras gecheckt, welche hood am nächsten ist; zumal es uns ja nicht um Meter-genaue Entfernungen, sondern nur um den relativ nähsten Hood-Mittelpunkt geht.
Mein zweiter Vorschlag: Wir verzichten auf Gateway ebene bis hin zum vpn Router auf Layer 2 und richten ein layer 3 Routing zwischen allen Routern ein. Somit würden wir. das batman auf die reine WLAN ebene begrenzen.
Der grundsätzliche Ansatz, das Mesh (wie genau auch immer) von unserer sowieso statischen Server-Infra fernzuhalten, macht denke ich Sinn. Auch hier kann ich wieder nur sagen: Muss man schauen, wie man das so konfiguriert bekommt.
Allgemein bevorzuge ich den ersteren Vorschlag. Ich stimme fkr da im übrigen voll und ganz zu. Der overhead ist in zwischen unzumutbar deswegen jetzt eine schnelle Lösung mit großer Wirkung,
ack. vollkommen richtige Äußerungen.
allerdings bin
ich da zurzeit auf Clemens Seite wir haben einige große Baustellen offen und die kosten uns viel zeit und nerven. Ich würde es sehr bevorzugen, wie Clemens das im Pad auch schon dargestellt hat, wenn wir uns genau überlegen wir wir das Netz Designen wollen damit es möglichst Skala bleiben soll.
Ehm, mag sein, dass wir verschiedene Baustellen haben, aber ein Freifunk ohne funktionierenden Freifunk wäre so ungeil, dass ich diesem Thema hier mal Priorität 0 zuweisen würde D:
Auch müssen wir berücksichtigen was wir mit Netz erreichen
wollen für mich ist es ein großes Forschungsnetz, wo man neue protocole und Möglichkeiten aufprobiert. Dazu gehört auch mal in eine Sackgasse zu fahren wie wir die jetzt haben. Wo wir fest stellen das unser Layer 2 Ansatz nicht funktioniert.
War ja irgendwo absehbar, aber wir können jetzt zumindest festhalten: bis etwa 800 nodes kann man das noch so gerade irgendwie keuchend am laufen halten D:
Gruß, Eike -----BEGIN PGP SIGNATURE----- Version: GnuPG v2
iQIcBAEBCAAGBQJVts+lAAoJEIu3uYB6vkH4JqcP/isrDIBI5DjG2udtOhuM+DEg jEh8AoodQqb+/3XSj/7Do9hb+eBd41/O9j2LE5LyAffP54+pa2wDBo0L0noI0cxv 4/fYI9q4flpmmX9TzknlUMYbz4WOyXK7+c8kMTBLpE8vGOd5HV2fMtCFZlxtbzFx QNEDRLk5oFXpeWJMQAdbdhVP/kCaoLa5nTrCZ8QYwk93/S2+NDV7RWdgGb4egXIp DHJPUxV5EofDkLFoNRZL7ExE+sR8r4r0W0+y2rahEMZbDyTI0t8WKUOcyQldId0h 1KGV818IlE8jdF2KFgyum96EJYGCV2Us1iKz/RbKcvfK7yi1wkBGheydcg6GUQQs cIWLDYUuWxO74f+C0c64t+HG2k9SOMvlz8dV5d/pgQTsKj+asosL2ZWTn4wZPnYJ 5WYcUpf6+xt8AHd6ZgMIo9zRQYicKTVOQfSeGxZ2qIDk/FyQB1q9x5EdzsiXqnHC pdREV77hLx9kZhVCodWW+zDvT2hYWYVy6PPcqxD9XSqMFkCLz2mjLH6JBwQhuuRi GVGOsbEVhDasWBI0Z3nuVi6gRKaJrarOBwKMTUgoVdAXkQnpE9IH3aYnA2AdXFlj /zG83lrt2RhXJMWkPoEXT7IHLOjGotDtyYtw206cVzu2pDT966K2oBLInNXNzyil ZwtfBrhNCw72UEOFERpD =4p5G -----END PGP SIGNATURE----- _______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Viele Grüße, Stefan