Erfahrungen mit Babel

Technik
41

Dann nehmt unsere Firmware, die ist mittlerweile so gut wie fertig (inoffizielle Firmware gibt es schon seit Jahren die sehr gut tut, in den „offiziellen Zweig“ fehlen noch 2-3 Kleinigkeiten) und die kann das, nicht ganz automatisch aber siehe anderer Beitrag das ist weder das Ziel noch der Wunsch.

Gruß

Christian

42

https://tools.ietf.org/id/draft-ietf-babel-applicability-03.html

Das ist von Oktober 2018 und führt die oben genannten Probleme auf. Und die Probleme ergeben auch Sinn, weswegen ich den Ansatz von @ChrisD schon sehr verlockend finde, ein Protokoll da einzusetzen wo es auch Sinn ergibt. Macht man ja im professionellen Stil nicht anders ;).

1 „Gefällt mir“
43

Ich habe kein Interesse daran eine Situation wie beim Meshviewer zu schaffen. Lass uns unsere Zeit und Ressourcen bündeln und gluon verbessern, wenn da was fehlt. Es ist durchaus erwünscht, dass Communities sich mit PR an gluon beteiligen.

2 „Gefällt mir“
44

Keine der von Juliusz in https://tools.ietf.org/id/draft-ietf-babel-applicability-03.html aufgeführten Probleme ist für unseren Anwendungsfall relevant.

  • wir führen (bislang?) keine routen-Aggregation durch. Probleme die durch Aggregation entstehen, haben wir also nicht.
  • Wir wissen, dass die full-table bequem in die Nodes passt
  • die periodic updates sind in unserem Anwendungsfall ein Vorteil. Wir haben große dynamische Netze. Low-Power-Devices spielt (noch?) keine Rolle. Wir haben den gelegentlichen Akku-Mesh-Node, aber das war es auch.
45

Der Overhead der aber bei unstabilen Links entsteht ist doch nicht verleugnenbar, wenn ich sehe wie oft bei uns Links flappen im Wireless muss das im großen Stil zu hoher CPU Last führen.

46

Ich zitiere mal Dave, der die tests mit den 50K routen durchgeführt hat: „You run out of bandwidth long before you run out of CPU or Memory“. Als Ergebnis wurden die Updates in babel etwas träger gemacht und die Anforderung an Bandbreite gesenkt.

Am Ende weiß es im Moment noch keiner. Sobald jemand wieder ein Netz mit 1K clients aufbaut und dabei den aktuellen Softwarestack (Stand jünger als Juli 2019) nutzt, werden wir irgendwelche Effekte sehen, etwas lernen und darauf basierend die Protokolle verbessern. Vielleicht lernen wir auch, dass 1K clients nicht mehr reichen um den Stack an die Wand zu fahren. Bis dahin ist das jedenfalls Kaffeesatzleserei.

5 „Gefällt mir“
47

Ich hab mal ein paar synthetische Tests gemacht. Ein TL-WR841 verträgt bis zu 15K routen. Es werden also bequem Netze bis 5K clients unterstützt.

2 „Gefällt mir“
48

Wieviele Router hattest du zum Testen? Und wieviel Bewegung im Netz?

49

ich habe in einer for-schleife 15K routen in die Routingtabelle eingefügt und alle 1000 routen 30 Sekunden gewartet und als client eine Webseite aufgerufen. Bei 16-18K routen (je nachdem ob zram an ist oder nicht) startet das Gerät neu. Man braucht für das Szenario nicht mehr als ein Gerät.

Es gibt noch andere Szenarios, die auch interessant sind bei denen man mehr Geräte benötigt - da ist man dann allerdings in dem Bereich in dem die Links und deren Bandbreite eine Rolle spielt, wodurch man nur noch situationsbedingte Aussagen ableiten kann. Da muss man dann selbst testen.

1 „Gefällt mir“