Geld sammeln - Belohnung für das Lösen der Auslastungsproblematik im Gluon (Issue #1243)

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 Likes

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 :slight_smile: .

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 Likes

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. :wink:

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 Like

8 Beiträge wurden in ein neues Thema verschoben: TP-Link WR841N(D) - Flash und RAM aufrüsten

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 :wink: 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 Likes

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 Likes

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 Likes

Auch 6 Monate später würde mich es noch immer interessieren was mit den restlichen 2000€ (?) geplant ist. Gab es weitere Schritte zur Verbesserung, Fehlerbehebung, Stabilisierung von Gluon etc?

1 Like

Wir sind für Ideen offen. Ich denke, da die OpenWrt-Community die 4/32er rauswirft, ist das Thema durch.

Wir sind gerade dabei zu prüfen, ob man die Geräte in großem Maßstab von Aufbereitern auf 16/64 aufrüsten lassen kann. Wenn man die Kosten auf 4-5 €/Gerät bekommt, wäre das realistisch.

Ansonsten bleibt zurückzahlen oder die Gelder sinnvoll verwenden.

Ich fände es z. B. hilfreich von den Geldern 200-250 841er aufzukaufen und damit einen ersten größeren Test zum Aufrüsten zu machen. Ob wir die Gelder dafür verwenden dürfen bzw. können müsste aber vorher geprüft werden.

Stimmen aus der Community sind daher hilfreich. Ich denke, wer sein Geld anteilig zurück haben möchte, kann das gerne bei uns beantragen. Anteilig, weil ein Teil ja ausgezahlt worden war.

PS: Letztendlich muss man auch sagen, dass die Gluon- u. Open-Wrt-Entwickler es geschafft haben, die übrigen Komponenten wie Batman so zu optimieren, dass 2019.1 wieder ganz passabel auf 4/32ern läuft. Da hat aber nie einer nach Geld gefragt.

Das Kernproblem ist denke ich einfach, dass die Community rund um OpenWrt begrenzte Ressourcen in Form von Programmierern hat und jetzt entschieden hat, die 4/32er rauszuwerfen, weil nicht nur der RAM zum Problem wird, sondern auch der Flash.

PPS: Wir erstellen mal ein unverbindliches Meinungsbild, weil ich noch nicht geprüft habe, wie die rechtliche Situation aussieht:

Restbetrag verwenden für:

  • 841er aufkaufen und umrüsten lassen
  • dem Gluon-Projekt spenden
  • dem OpenWrt-Projekt spenden
  • zurückzahlen

0 Teilnehmer

PPPS: Es geht übrigens um die verbleibenden 1996,4 €. 30% sind ausgezahlt, also gäbe es maximal 70% zurück, falls der Weg gewählt werden sollte, was ich nicht hoffe.

Vllt. nochmal zur Erklärung, warum ich von 841ern „aufkaufen“ spreche: Um die Logistik beherrschbar zu halten, wäre mein Ansatz, dass wir einen Pool von 250 841ern haben, die durchgetauscht werden können.

Also man lässt die aufrüsten, bespielt sie mir passender Firmware sodass sie dann vor Ort bei den Freifunkenden oder in den Communities per Direkttausch ersetzt werden können. Also tauscht man die nach und nach gegen alte nichtaufgerüstete aus. Wenn man wieder eine Charge von 250 zusammen hat, lässt man die umrüsten. Und das wiederholt man, bis man alle umgerüstet hat.

Dafür braucht man aber erstmal 250 von den Geräten. Und selbst bei einem Stückpreis von 10-15 € sind das eben 2500 bis 3750 €.

Details hatte ich mal hier aufgeschrieben: Geräte mit 4 MB Flash und 32 MB RAM aufrüsten - #30 von MPW

1 Like

Würde mich sehr interessieren, was da herauskommt. Mir hat jemand gesagt, dass die Kosten für den Austausch der Chips bei 30-40€ liegen würden, wenn das bei ihm in der Firma in Masse in Auftrag gegeben werden würde, weil die Personalkosten dafür zu hoch sind und man das nicht mit Robotern machen kann. Kann sein, dass es in Polen günstiger ist, aber ich glaube man müsste das schon nach Afrika schicken, um auf nen guten Preis zu kommen und es ist verboten, defekte Geräte (auch zur Reparatur) nach Afrika zu schicken. Mit dem finanziellen Anreiz stimme ich dir aber zu. Es macht keinen Spaß, so viel Zeit dafür zu opfern. Ich finde es fair, wenn man den Löter dafür ein wenig entlohnt. Nehmen wir mal an mit Reinigung des Gehäuses, der Platine etc. und mehr Konzentration als Zeitdruck braucht man eine halbe Stunde pro Router. Ein „Stundenlohn“ von 10€ wäre motivierend für einen heranwachsenden. Also sagen wir mal er oder sie kriegt 5€ pro Router. Darin solltet ihr investieren. Dann habt ihr Jugendliche glücklich gemacht und ihnen auch noch professionelles Löten beigebracht.

Ansonsten gibt es ja auch noch den Memory Leak in ath9k bei hoher Clientanzahl. Ich denke man könnte da mit dem Geld auch einen kleinen Ansporn schaffen.
Falls ihr euch entscheidet, stattdessen Router zu kaufen, dann vielleicht von einer Freifunkcommunity, die sich gegen einen Umbau entschieden hat, denn da gibt es welche, die noch massig Router haben. eBay sollte von dem Geld nicht gefördert werden.

250 Router sind übrigens mehr als benötigt. 50-60 Router reichen für ein Austauschprojekt meiner Erfahrung nach - für fast jeden abgegebenen Router kommt ja ein neuer rein.

2 Likes

DA BIN ICH FÜR!

3 Likes

Das halte ich für einen unseriösen Preis. Wie gesagt, es geht um Masse. Die nehmen dann auch keine große Rücksicht auf Plastiknasen. Aufbrechen, auslöten, einlöten, zuschrauben. Die Chips legen wir vorgefläscht und zugeordnet bei.

Jemand aus dem FF-Umfeld macht das beruflich und holt derzeit Angebote ein. Es kommt für uns nur osteuropäisches Ausland in Frage. Für den temporären Export und Wiedereinfuhr in die EU, ist uns der Papierkram zu viel Aufwand. Aber ja, wir dachten auch an Polen. Versandkosten sind ca. 2 € pro Gerät.

Halte ich für utopisch da eine Kinderarbeitsmanufaktur aufzubauen. Wir haben das bei uns in großer Runde diskutiert. Es kommt für uns nur in Frage, wenn die Hardwarearbeiten eine Firma macht.

Alleine die Orga und das Auslesen der WLAN-Kalibrierung und das Vorfläschen der zu verlötenden Chips sind mehr als genug Arbeit, die wir dann übernehmen.

Klar, falls ja, werden wir hier im Forum ein Gesuch einstellen.

Ne, das ist die absolute minimale Charge, die so ein Aufbereiter annimmt. Normaler Weise geht es da um vier- oder fünfstellige Stückzahlen, die da durchgehen. Daher braucht man ein gewisses Kontingent an Arbeitsgeräten.

Wir sollten erst A vor B lösen. Wenn wir die Geräte nicht aufgerüstet bekommen, gehen die ohnehin in den Müll und das Netz schrumpft auf einen Bruchteil zusammen.

Aber ich denke, da kann man ggfs. nochmal neu sammeln, wenn man das Speicherproblem gelöst hat.

Aber ich füge es trotzdem mal oben hinzu. Man kann ja bei diesem Abstimmungsmodi seine Stimme nochmal ändern. Geht leider nicht mehr.

Wenn diese Option von größeren Interesse ist, müssen wir neu abstimmen. Aber wie oben geschrieben, ich würde erstmal ein Problem lösen, bevor das nächste drankommt.

1 Like

Bevor dieses Thema in die ewigen Jagdgründe geht:
Auch 5 Monate später würde mich es noch immer interessieren was mit den restlichen (rund) 2000€ geplant ist. Gab es weitere Schritte zur Verbesserung, Fehlerbehebung, Stabilisierung von Gluon etc?

Vielleicht sollte man sich doch mal externe Hilfe suchen?
Zum Beispiel:
https://www.bountysource.com oder
https://bountify.com

2 Likes

Der Bug an sich ist weitestgehend gelöst, soweit ich das verstanden habe. In abgespeckter Version ohne OPKG gibt es mit 2020.1 eine Gluon-Version die ganz passabel auf den 841ern laufen soll.

Es ist nach wie vor geplant, die Gelder in die Aufrüstung zu stecken. Wir scheitern gerade daran, ein paar Geräte aufzurüsten, um sie dem Aufrüster zu zuschicken. Wir haben uns Lötequipment bestellt und probieren es weiter.

Wäre es nach so einer langen Zeit nicht vielleicht noch einmal sinnvoll über einen anderen Einsatzzweck nachzudenken / abzustimmen? Schließlich hat sich in der openwrt/gluon Entwicklung einiges geändert und die meisten Communitys sich sich einig die schwachen Geräte (841 & Co) nicht mehr auszurollen etc.
Es gibt sicher noch weitere Issues die beseitigt werden können/müssen…
Man muss ja nicht das komplette Geld für nur einen Zweck verwenden? Der FFRL würde sich sicher auch über eine Spende freuen …oder…oder …oder

Aber vielleicht bin ich auch der einzige der sich nach gut 1 1/2 Jahren fragt was mit den Spendengeldern so passiert…

Also bei einem kurzen Test von mir war die RAM Auslastung bei 2020.1 auf 841ern höher als mit 2019.x und 2018.x
Sogar so hoch, das ich nicht mal top aufmachen konnte, ohne das ich direkt nach dem öffnen die SSH Verbindung verlor.