Neue Snapshot Firmware 0.7.2

Hallo zusammen,

gestern Abend ist das gluon v2015.1.1 maintenance release Link veröffentlicht worden sodass ich nochmal eine neue Snapshot Firmware gebaut habe.

Ich denke die Fixes sollten wir mitnehmen und testen bevor wir in der nächste Woche die v2015 als Stable ausrollen.

Viele Grüße,
Lars

1 Like

Hab die VM und meinen 3600er auf die aktuelle Version „gezwungen“ - sieht gut aus.

Die VM (@work) werde ich mir tagsüber hin und wieder ansehen, den 3600er (@home)
kann ich nur aus der Ferne beobachten also erst heute Abend „quälen“ :wink:

Die VM ( http://map.freifunk-moehne.de/meshviewer/#!n:080027180c4d ) hat sich ganz wacker geschlagen.
Baut VPN für 4x Nanos und 841er auf (z.Z. 16:57 ca. 50 Clients)

Tunnel zu Möhne103 mit 90% - da sind aktuell 296 Nodes dran

@MrMM hat in einem anderen thread mal das Stichwort „Hop Penalty“ fallen lassen…
wäre das eine Möglichkeit die Supernodes gerechter auf die Nodes zu verteilen?

Wie auch immer, schweife grade ab :wink:
DIE FIRMWARE LÄUFT BEI MIR STABIL

Was erreichst Du für einen Durchsatz auf der VM?

Da es nur ein 16.000er DSLer ist den wir uns mit der Bücherei teilen ist da nicht viel zu erwarten…

Hatte grade bei ca. 50 Clients ( an 8 nodes) 4500 download - waren heute morgen zur Knoppers-Zeit ca. 10.000 down ( hatte da aber die Clients nicht gezählt)

Werden nach den Ferien wohl endlich einen 50.000/5.000 UM Anschluss bekommen - bin gespannt was dann möglich ist…

Habs drauf.
Mit dem Ergebnis, das mein node nun nur noch offline angezeigt wird.
Es nervt…

chris

http://map.freifunk-moehne.de/meshviewer/#!n:14cc205a682a

Ich hab gerade mal von Stable auf Snapshot umgeschaltet und geupdatet…
Aktuell schlagen keine Flammen aus dem Gerät - schätze das ist prinzipiell ein gutes Zeichen! :smile:

http://map.freifunk-moehne.de/meshviewer/#!n:e894f6bbae36

Ich hab 3 Knoten damit laufen. Bisher alles tutti.

Kurz zu den x86-Images:

Ich und @Groman haben auch mal mit den x86-Offloadern herumexperimentiert.
Ergebnis ist, dass es aktuell eigentlicht nicht sinnvoll ist einen x86-Offloader ins Möhne-Netz zu bringen. Der Durchsatz lässt jetzt keine Freudensprünge zu, da das Nadelöhr wohl nicht beim Offloader, sondern vermutlich bei den Supernodes liegt.
Bei meinen Tests erreiche ich immer um die 10-15MBit (egal welche Uhrzeit oder welchen Supernode ich anspreche).
Das kann ein 1043v2, 3600, 4300 o.ä. auch leisten.

Die ganze Nummer ist nur dann sinnvoll, wenn auf der anderen Fastd-Seite eine performante Gegenstelle wartet.
Insgesamt also eher ein ernüchterndes Ergebnis. Zumindest was die Fastd-Performance angeht.

1 Like

@Administratoren
bitte mittelfristig mal eine „performante Gegenstelle“ (exlusive für VMs) zur Verfügung stellen.

Damit der Testsupernode explizit für Test-VM-Offloader zur Verfügung steht am besten
parallel zum Supdernode eine angepasste Firmware für die VMs bereitstellen :wink:

ggf. gibt`s ja mit der kommenden Limitierung auf nur noch eine VPN Verbindung bereits
die notwendigen Kapazitäten

(haben am 2. Sonntag im August Schützenfest, könnte also ein Szenario für einen Stresstest anbieten)

Ich glaube jetzt hast Du bei nem Admin, aufgrund der Finanzlage des FFRL, maximal ein süffisantes Lächeln provoziert. :wink:

Humor ist wenn man trotzdem lacht :wink:

… man wird ja noch seinen Tagträumen hinterher hängen dürfen. :zzz:

Wir haben bereits eine Hop Penalty von 120. Das ist aber auch wie im verlinkten Beitrag erwähnt nur dafür da um den VPN Traffic zu entlasten wenn man innerhalb einer Wolke arbeitet und auch einen Route ohne VPN.hat.

Man müsste den Wert (hier 225) irgendwie verändern können aber ich weiss noch nicht wie und wann der sich ändert.

root@ff-abg-bergheim-i41t:~# batctl gwl
      Gateway      (#/255)           Nexthop [outgoingIF]: gw_class ... [B.A.T.M.A.N. adv 2013.4.0, MainIF/MAC: eth0/c4:6e:1f:e7:ce:18 (bat0)]
   04:af:fe:02:01:03 (116) 00:11:95:66:08:2f [      eth0]: 215 - 96MBit/96MBit
   04:af:fe:02:01:02 (119) 00:11:95:66:08:2f [      eth0]: 215 - 96MBit/96MBit
   04:af:fe:02:02:04 (116) 00:11:95:66:08:2f [      eth0]: 215 - 96MBit/96MBit
   04:af:fe:02:02:03 (119) 00:11:95:66:08:2f [      eth0]: 215 - 96MBit/96MBit
   04:af:fe:02:02:01 (116) 00:11:95:66:08:2f [      eth0]: 215 - 96MBit/96MBit
   04:af:fe:02:02:02 (119) 00:11:95:66:08:2f [      eth0]: 215 - 96MBit/96MBit
=> 04:af:fe:02:01:01 (225) 00:11:95:66:08:2f [      eth0]: 215 - 96MBit/96MBit
   04:af:fe:02:00:03 (119) 00:11:95:66:08:2f [      eth0]: 214 - 96MBit/84MBit
   04:af:fe:02:00:01 (114) 00:11:95:66:08:2f [      eth0]: 215 - 96MBit/96MBit

@nullu Manuel? Ich kann Dir gedanklich gerade nicht folgen, wo Du ansetzen willst. :slight_smile:

Tja was wollte ich eigentlich sagen? :wink:

Ich wollte nur erklären, dass Hop Penalty jetzt nicht unbedingt etwas mit der 296fachen Auswahl von 103 als Gateway zusammen hängt.

Natürlich wäre ein besseres balancing hier von Vorteil.

@nullu Kehr, wir haben den Fred hier doch schon mit x86-Testereien verwässert, jetzt kommt Du mir doch nicht mit nem Topic von ganz oben. Ich war kurzzeitig verwirrt. :smiley: :wink:

@biggesee, @sirexeris
Ihr könnt aktuell mit der 204.freifunk-moehne.de testen.
Sie wird nur von Nodes mit Snapshot Firmware angesprochen und ist im Moment wenig ausgelastet.

Bis zum Schützenfest wird der Zustand vermutlich nicht anhalten aber vielleicht haben wir bis dahin ja was neues :wink:

@Lars das hab ich versucht - mehr als die von @sirexeris angesprochenen 15mbit gabs dennoch nicht

Auf die Idee bin ich auch gekommen. Hab alle Peers deaktiviert und nur noch 204 zugelassen. Zum Testzeitpunkt waren auf 204 nur 20 Nodes verbunden. Aber auch da: Mehr als 13MBit hab ich da nicht geschafft und das schafft dann auch mein 3600. Die Frage ist, ob überhaupt mehr als 15MBit drin sind, oder wo das potentielle Nadelöhr ist.

Hm, okay.
Ich hab schon eine Vermutung, nicht alle unser Supernodes haben eine eigene GRE Anbindung an den FFR und vermutlich kostet das weiterleiten etwas Performance.

Mal schauen ob wir das noch optimieren können.

1 Like