Was heißt 2018er, v2018.1.x oder v2018.2.x?
Ein Patch für v2018.1.x mit LEDE 17.01 Unterbau wird wenig hilfreich und schon gar nicht zukunftsorientiert sein…
1 „Gefällt mir“
Die aktuelle Münsterland-Firmware (4.0.1) basiert auf Gluon 2018.2.
2 „Gefällt mir“
Ich habe inzwischen ein neues Testfeld aufgebaut und konnte den Fehler nicht mehr reproduzieren.
Die getestete Firmware basiert auf dem 2018.2.x von ca. Anfang Februar. An der Münsterland-spezifischen Konfiguration hat sich nicht viel geändert.
Lediglich das Mesch auf 11s umgestellt. Wir verwenden allerdings kein VXLAN.
Das typische Ansteigen der Auslastung bei LAN-Verbindungen ist bei mir zumindest weg.
https://karte.freifunk-muensterland.de/map04/#!v:m;n:a42bb0d21ba4
Die 841er laufen wieder so stabil wie eh und je. Wäre richtig geil, wenn wir mal alle Knoten aktualisieren könnten und trotzdem die 841er weiter laufen. Bin da gerade sehr euphorisch nach den frustrierenden anderthalb Jahren davor 
.
Hat noch jemand Probleme?
Viele Grüße
Matthias
1 „Gefällt mir“
das heißt aber nur, dass die RAM-Auslastung gesunken ist, nicht, dass es keinen Fehler mehr gibt (sofern es je einen gab).
Wie @anon88999732 dir auch schon schrieb, tritt das Problem weiterhin auf, wenn man die RAM-Auslastung manuell erhöht.
2 „Gefällt mir“
Das denke ich auch. Die Frage ist, wie man das systematisch weiter angeht?
Soweit ich es verstanden habe, ist es eigentlich ein OpenWRT-Problem und nicht gluon-spezifisch.
1 „Gefällt mir“
Ram-Aufrüstsets anbieten und SMD-Lötworkshops in Hackspaces abhalten?
1 „Gefällt mir“
Durch etwas Traffic am Lan-Port (nicht im MOL Betrieb) kann man das Problem leicht reproduzieren.
Auch noch mit gluon 2018.2
1 „Gefällt mir“
@TomS, kannst du vllt. dem @anon88999732 eine Testplattform bereit stellen? Er wollte sich das glaube ich nochmal ansehen.
Bei mir konnte ich es bislang nicht reproduzieren. Aber das heißt ja nicht, dass das Problem weg ist.
Freue mich sehr, dass es hier weiter geht 
1 „Gefällt mir“
@TomS, kannst du vllt. dem @anon88999732 eine Testplattform bereit stellen? Er wollte sich das glaube ich nochmal ansehen.
Ja, kann ich. Gerne.
3 „Gefällt mir“
Der Grund für die hohe Load ist ja bekannt. Wenn der Router so wenig Speicher hat, dass er die Dateien nicht mehr im Cache halten kann, lädt er sie kontinuierlich vom Flash bzw. von SquashFS. Da das ganze in blöcken komprimiert ist, muss er selbst für kleine Dateien einen großen Block lesen und den auch noch dekomprimieren. Dieses Fehlerbild nennt man Thrashing und kennt man auch vom Heim-PC, wenn der nicht genug Speicher hat. Das Problem ist auch den SquashFS-Entwicklern bekannt, dass das Thrashing nicht erkannt wird. Ich hatte mal die Android-Patches von SquashFS ausprobiert, die die neue BIO-API benutzen. Da wurde der Thrashing-State anscheinend erkannt, aber das führt nur dazu, dass der OOM-Killer angeworfen wird. Da es anscheinend nicht wirklich etwas an Speicher gab, den man freimachen konnte, hat das nach ein paar Minuten zum reboot durch eine OOM-kernel panic geführt. Ob es besser ist, wenn der Router statt eine hohe Load zu haben, kontinuierlich rebootet ist fragwürdig.
Wieso manche Router betroffen sind und andere, obwohl sie viele Clients haben, Mesh-on-LAN und wer weiß was machen, fehlerfrei laufen, ist mir auch noch ein Rätsel. Bisher konnte ich nicht nachvollziehen, wieso manche Router auch ohne Last so viel Speicher benötigen.
Mit dem Wechsel von LEDE auf OpenWrt sieht die Speicherauslastung wesentlich besser aus. Ich habe hier noch ein paar unfertige Patches rumliegen, um die sie noch weiter zu verringern, aber dafür muss ich bei OpenWrt ein paar Dinge einreichen, auf die die Entwickler dort wahrscheinlich gerade nicht so viel Lust haben. Die haben genug mit dem Wechsel auf den kernel device tree zu tun.
Aktuell kommen bei mir auch jeden Tag mehr Baustellen dazu, als ich beseitigen kann. Deshalb habt bitte Geduld. Ich setze mich bald wieder an das Problem und ich bin zuversichtlich, dass die 4MB/32MB-Geräte noch ein paar Gluon-Releases ihren Dienst tun werden, auch wenn ich dringend davon abrate, noch mehr von den Dingern ins Netz zu bringen. Auch das Splitten der Netze in Domains ist etwas, um das langfristig keine Community herumkommen wird, auch nicht mit Babel, egal wie viel Speicher die Router haben. Deshalb empfehle ich die Load-Problematik als Anlass zu nehmen, das jetzt in die Hand zu nehmen.
Die Kernelentwickler grübeln aktuell übrigens, wie sie Thrashing, den Dateisystemcache und Memory handling allgemein verbessern können. Ich bin zuversichtlich, dass sich die Situation mit neueren Kernelversionen eher verbessern wird. Die Komplexizität hat sich nicht erhöht, was der Router macht. Wenn aber nicht auf Geräte mit mehr Leistung gesetzt wird, setzen wir Gluon künstliche Grenzen.
Und im schlimmsten Fall (bevor einem die Freifunknetze wegsterben, weil zu viele 841er verbaut sind) kann man immer noch viel Arbeit darein investieren, bei SquashFS die Unterstützung von unkomprimierten Blöcken zu verbessern und dafür kein Caching zu machen. Denn die 4MB-NOR-Flash-Speicherbausteine sind schneller beim Lesen als z.B. NAND und sollten eigentlich sogar fast schnell genug sein, um Programmcode direkt davon auszuführen.
Um zum Punkt Hardware für die Zukunkft zu kommen, auch wenn ich hier etwas ausschweife. Ich kenne das Problem selbst, dass man Leute schlecht überzeugen kann, teurere Geräte zu kaufen, aber unser Netz ist auch nur so gut wie die verbaute Hardware. Das muss man im Einzelfall abwägen. Ich bin z.B. kein Freund von den Mediatek-Chipsätzen. Für mich sind das Billig-Chips für die Dritte Welt. Eine FritzBox 4040 mit IPQ-WLAN Quad-Core ARM-Prozessor ist eine ganz andere Hausnummer und wird auch noch in 10 Jahren genug Durchsatz machen, denn aktuell konzentriert sich die Routerbranche eher auf die 3. Welt. Die drastische Entwicklung, die wir in den letzten Jahren beobachtet haben, stagniert. Die nächsten Schritte für die WLAN-Chiphersteller sind 160 MHz Kanalbreite auf 5 GHz, was an den Frequenzfreigaben scheitert, das zusammenschalten von 2.4 und 5 GHz, was wir für Mesh nicht unbedingt wollen und an den höheren Produktionskosten für Chips, die soetwas ohne Störungen beherrschen, scheitert und Phased-Array-Antennen, die die Produktionskosten aufgrund der vielen Signalpfade in die Höhe treiben und dafür sorgen, dass die Router aussehen wie Thermoskannen. Deshalb geht es jetzt bei den Routerherstellern gerade darum, erst einmal der 3. Welt Router zu verkaufen und die Kosten noch weiter zu senken. Bis dahin ist eine FritzBox 4040 high-tech… Seid mir aber bitte nicht böse, wenn in 10 Jahren dann doch auf einmal überall WLAN mit Masern und fraktaler Kodierung läuft, weil die chinesische KI neue Fertigungstechniken entwickelt hat und wir pro Person mindestens 20 GBit/s brauchen, um mittels unserer Neuroimplantate vernünftig League of LegendsVR spielen zu können. Erinnert euch dann bitte an Bill Gates Ausspruch „ 640 kB sollten eigentlich genug für jeden sein“. Als Hobby-KI-Forscher halte ich das Szenario aber für unwahrscheinlich, da selbst eine starke KI auch nur ein updatefähiger Mensch mit mehr Rechenleistung und einem weniger fehleranfälligem Nervensystem ist. Die Frage ist natürlich, ob man in einem solchen Szenario Freifunk überhaupt noch braucht.
13 „Gefällt mir“
Moin @anon88999732,
danke für deinen ausführlichen Beitrag und ich stimme dir voll und ganz zu, dass man in teurere Router investieren sollte. Meiner Meinung nach ist die Zeit der Massenrouteraufstellung ohnehin vorbei und die meisten Freifunkcommunities bauen einzelne Standorte mit qualitativ hochwertiger Hardware aus. Nicht zuletzt haben 841er und andere ältere Geräte auch unter nicht ganz optimalen Funkbedingungen so niedrige Durchsatzraten, dass viele lieber LTE nutzen.
Dein Erklärungsansatz zielt auf den höheren Ram-Verbrauch durch den moderneren Kernel ab.
Was ich aber nicht verstehe ist, der RAM war bei 841ern immer schon relativ voll. Nehmen wir mal dieses Geräte: https://karte.freifunk-muensterland.de/map16/#!v:m;n:18d6c7902824
89% RAM-Auslastung läuft und super stabil.
Ist es eine der unerklärlichen Ausnahmen? Ich halte es schon nicht für unwahrscheinlich, dass ein Patch zwischen 2016 und 2017 die Situation verschlimmert hat. Den SquashFS-Bug mit dem Trashing mag es vorher schon gegeben haben oder nicht. Das erklärt für mich zumindest nicht bis in Detail warum sich die Situation zu 2017 schlagartig so dramatisch verschlechtert hat und warum trotz der starken Optimierungen für 2018 nicht wieder das Niveau von 2016 erreicht wurde.
Bitte nicht falsch verstehen, ich bin relativer Laie auf dem Gebiet. Es ist einfach nur eine Beobachtung, die meiner Meinung nach nicht zu deiner Erklärung passt. Ich will mir aber auch nicht anmaßen, es besser zu wissen .
Viele Grüße
Matthias
Hi Matthias,
ein neuerer Kernel sollte normalerweise keinen höheren RAM-Verbrauch haben. Ja, es gab einige Änderungen im Kernel, die zwischenzeitlich womöglich einen höheren RAM-Verbrauch verursacht haben und einige Konfigurationsparameter bei LEDE. Viel schwerwiegender ist jeder einzelne Prozess, der bei Gluon dazukommt oder auch jeder einzelne zusätzliche Schritt bei der Paketverarbeitung kann unter Umständen eine größere Speicherauslastung verursachen. Was im Endeffekt den Unterschied ausgemacht hat, kann ich nicht sagen. Und es gibt ja immer noch Router mit der neuen Gluon-Version, bei denen das Problem auftaucht, die augenscheinlich nichts tun. Vielleicht kommt auch noch heraus, dass irgendetwas schief gelaufen ist, aber ich habe mir alle Änderungen, auch im Kernel, zwischen den Versionen angeguckt und ich konnte von keiner sagen „Das ist sie“.
Dass der Router immer ca. 89% RAM-Auslastung anzeigt liegt daran, dass mehr virtueller Speicher benötigt wird, als physisch zur Verfügung steht. Wenn z.B. ein Programm eine große Datei öffnet, dann wird den Daten ein virtueller Speicherbereich zugewiesen, obwohl die Daten nicht im RAM, sondern auf der Festplatte bzw. dem Flash liegen. Der Kernel nutzt seinen RAM so gut aus wie möglich bzw. wenn der virtuelle Speicherbedarf größer ist als der physische RAM, werden nur Daten vom RAM gelöscht, wenn etwas mit einer höheren Priorität Speicher verlangt. Die 10%, die „frei“ sind, sind reserviert für Datentypen, die die höchste Priorität haben, wie z.B. Netzwerkpakete. Der Wert ist irreführend. Wenn man den cache frei macht (echo X > /proc/sys/vm/caches), dann sieht man, wie viel Speicher tatsächlich frei ist. Und das waren bei einigen Geräten mit dem Load-Bug nicht einmal 1MB. Bei X=1 wird der Page Cache frei gemacht. Das sind hauptsächlich Dateiinhalte. Bei X=2 werden inodes und dentries freigemacht. Das ist sozusagen die Datei- und Ordnerstruktur. X=3 löscht beides. Damit ein Router vernünftig Pakete verarbeiten kann, braucht er eine gewisse Größe des SLAB-caches. 16 MBit/s sind quasi 2MB die da pro Sekunde freigemacht und alloziiert werden. Das sollte nicht noch zusätzlich warten müssen, dass da Speicher aufgeräumt wird. Da kämpft quasi das Dateisystem mit dem Netzwerkstack und das Dateisystem liest jedes mal riesige Blöcke vom Flash und dekomprimiert sie. In der Zeit guckt der Netzwerkstack in die Röhre, weil das eine Single-Core-Maschine ist, der ath9k-Treiber kriegt seine Beacons nicht mehr rausgeschickt und fängt an seinen Chip zu resetten, weil der denkt damit stimmt was nicht. Thrashing sollte nicht passieren. Sonst ist das System hinüber.
Lieben Gruß,
Vincent
7 „Gefällt mir“
Ah danke, dass schon quasi unter 2016 munter geswappt wird, war mir gar nicht bewusst. Danke für die tolle Erklärung.
Tja, dann hilft nur drauf hoffen, dass du Zeit und Motivation findest, dir das nochmal anzusehen. 
Wenn wir dich irgendwie unterstützen können, sag gerne Bescheid. Sei es in Testsetups oder mit Werkzeugen.
Um nochmal auf das hier zurück zu kommen:
Könnte man das nicht evtl. über einen Förderantrag finanzieren? Wenn man da einen Profi zwei drei Wochen dran setzt und da irgendwie mal 15k € investiert?
Das ist ja kein Rumstochern, wo die Zeit vorher nicht abschätzbar ist, sondern es wäre eine konkrete Funktion, die es zu implementieren gilt. Der Aufwand müsste natürlich vorher realistisch geschätzt werden.
Deshalb habe ich den SquashFS-Entwickler schon einmal angeschrieben und leider keine Antwort erhalten. Ein Google-Entwickler hat schon Änderungen daran gemacht, aber die sind abgelehnt worden, weil er ein anderes Feature dafür geopfert hat. [PATCH 5/5] Squashfs: optimize reading uncompressed data - Daniel Rosenberg
Die Antwort vom SquashFS-Entwickler war
Let’s be clear. Your reason for removing FILE_CACHE is simply because
when adding your new whizzo feature, you needed to update both the
FILE_CACHE and FILE_DIRECT code, and as you didn’t use FILE_CACHE,
you couldn’t be bothered to update it, and removed it instead. This
is not a valid reason for removing it.
Bisher bin ich noch nicht so weit gekommen, zu verstehen, ob das möglich ist, das einfach anzupassen. Ich habe zwei mal versuch mich in den Codeeinzulesen, kratze aber von meinem Verständnis her immer noch an der Oberfläche.
1 „Gefällt mir“
Bei uns tun immer noch viele 841er mit gluon 2016 klaglos ihren Dienst.
Und für kleinere Installationen mit nicht vielen Usern absolut zufriedenstellend.
Da sind auch über 30Mbs über L2TP drin.
Es geht einfach nur darum, dass man jetzt nicht alle diese Nutzer vor den Kopf stößt und sagt sie sollen die Kisten wegwerfen. (die wenigsten könnten da dran rum löten)
Als alter Freifunk-Tüftler bin ich natürlich auch dran interessiert, die Kisten mit einem aktuellen Gluon vernünftig zum Laufen zu bringen 
und biete da meine Unterstützung an, sei es mit eigenen Tests oder mit zur Verfügung stellen einer Testplattform.
Denke wir können alle nur lernen dabei, egal an was es dann im Endeffekt lag.
2 „Gefällt mir“
Das Generationenproblem wird ja immer wieder mal kommen. Ist es nicht besser ein Freifunknetz V2 zu initiieren anstatt an alten Problemen weiter zu murxen? So kann man dann in ein paar Jahren dann das erstere schließen und ein V3 daraus machen usw.
Mit den 2017.x Versionen habe ich durchaus auch Probleme mit zu hoher load gesehen. Auf Basis von 2018.2 planen wir wieder eine Stable zu veröffentlichen da die load hier sehr gut aussieht. Zumindest sagen das meine Statistiken für die Regio Aachen.
Dies ist jeweils der maximale load Wert pro Modell:
Exemplarisch nur für die 841v9:
Das sieht für mich so aus als wären wir mit der 2018.2 besser dran als mit 2016.2.7
4 „Gefällt mir“
Link zum den Dashboards:
https://grafana.ffac.rocks/d/UhC9LqCmz/load-by-gluon-version-per-nodename
https://grafana.ffac.rocks/d/DKkbPqjmz/load-by-gluon-version-by-model
3 „Gefällt mir“