Ffrn-lowmem-patches

Technik Gluon
1

Über das Gluon Issue #753 und hier das Thema “Firmware 0.5.8 verfügbar (Load Patch)” habe ich den Patch “ffrn-lowmem-patches” gefunden, der bei Nodes mit RAM < 40 MB helfen soll, bei vielen Clients im Netz einen Crash zu verhindern.

  • Wieviele betroffene Nodes sind im FFRN-Netz schon damit ausgestattet?
  • Wie sind die Erfahrungen damit, gibt es Nebenwirkungen?
  • Dürfen wir beim Freifunk-Stuttgart ggf. den Patch in unsere FFS-Firmware integrieren?
2

Müssten > 500 sein, wenn die Statistiken in unserer Karte nicht lügen.

Wir haben an zahlreichen Stellschrauben gedreht, und irgendwie hat alles ein wenig geholfen. Negative Nebenwirkungen wüsste ich von den Patches bisher keine.

Selbstverständlich!

3

Wir haben heute eine Firmware auf Basis von Gluon 2016.2.1 mit den Patches gebaut und begonnen, damit zu testen. Nach der schlechten Erfahrung mit unserer v2016.2 werden wir allerdings dieses mal eine ausreichende Testphase vorsehen, bevor die neue FW flächendeckend ausgerollt wird.

1 „Gefällt mir“
4

In /usr/sbin/ffrn-lowmem ist ein Fehler. Beim allerersten Start eines Nodes mit < 40 MB RAM direkt nach dem Flashen, wo er automatisch in den config mode geht, wird haveged gestartet und dann deaktiviert und gestoppt. IMHO sollte das script korrekt so aussehen (relevanter Teil):

# start haveged in config mode
MODE=`uci get gluon-setup-mode.@setup_mode[0].enabled`
if [ $MODE == "1" ] ; then
    /etc/init.d/haveged start

# disable and stop haveged if enabled
elif [ -f /etc/rc.d/S13haveged ] ; then  # im Original ist das auch beim 1. config mode aktiv
   /etc/init.d/haveged disable
   /etc/init.d/haveged stop
fi

Bei den Tests in Stuttgart mit WR841N sieht es ausserdem so aus, als sei die CPU-Load höher, wenn der Original-Patch benutzt wird. Ohne Reduzierung der Thresholds bei den sysctls sieht es besser aus, d.h. ohne die Zeilen

/sbin/sysctl -w net.ipv6.neigh.default.gc_thresh1=64
/sbin/sysctl -w net.ipv6.neigh.default.gc_thresh2=128
/sbin/sysctl -w net.ipv6.neigh.default.gc_thresh3=512

/sbin/sysctl -w net.ipv4.neigh.default.gc_thresh1=64
/sbin/sysctl -w net.ipv4.neigh.default.gc_thresh2=128
/sbin/sysctl -w net.ipv4.neigh.default.gc_thresh3=512

Die anderen sysctls sind weiterhin aktiv im Script.

5

Hallo Roland,

ich vermute Du hast recht. Ich habe nochmal durch die History geschaut, und kann nachvollziehen, was passiert ist:

Erst sah es so aus:

if [ $MODE == "1" ] ; then                                  
     /etc/init.d/haveged start
    fi
    # disable haveged if enabled
    if [ -f /etc/rc.d/S13haveged ] ; then                   
        /etc/init.d/haveged disable
    fi
fi

Dann ist aufgefallen, das nach dem ersten Starten nach dem Config-Mode der haveged noch lief, und erst beim zweiten reboot komplett weg war. Dadurch ist der stop reingekommen, der ohne den elif Fall natürlich falsch ist.

Danke für den Tip! Machst Du einen Pull-Request dazu?

6

Ich habe (leider) keine passende Entwicklungsumgebung eingerichtet - bin mehr im Bereich Tests + QC unterwegs. Könntest Du die Korrektur vielleicht selber übernehmen?

7

Wir haben inzwischen in Stuttgart beschlossen, euren Patch in der Originalform nicht zu benutzen, sondern lediglich den (korrigierten) Teil bzgl. “haveged” als Fork, selbstverständlich mit Quellenangabe.

Die anderen Teile haben leider Nebenwirkungen oder keine, wie die Tests mit WR841N gezeigt haben:

a) Absenken der Thresholds für den Garbage-Collector bei gleichzeitiger Verlängerung der GC-Intervalle führt zu unzuverlässiger Erreichbarkeit der Nodes per IPv6, z.B. Statusseite oder SSH oder auch Ping6. Der Client-Traffic via batman-adv ist davon nicht betroffen.

b) Verändern des Verhaltens bei dirty Memory Pages, so dass früher begonnen wird, mit Hintergrund-Prio die dirty Pages auszulagern, und die Hürde für den Sync Mode anzuheben, sowie die zeigesteuerte Auslagerung abzuschalten, funktioniert in der Praxis leider nicht wie gewünscht. Die CPU-Last steigt sehr deutlich an, sobald Im Netzwerk erhöhter Traffic ist (beginnt bei ca. 750 Clients + 280 Nodes). Es ist dabei so, dass bei “top” die “load” und nicht die “%CPU” ansteigt: load in peaks bis 1,8 aber 60% CPU idle.

c) Erhöhen von “vm.min_free_kbytes”, damit die zeitkritischen Prozesse nicht erst mühsam RAM freischaufeln müssen, also bei 32 MB Gesamt-RAM vom Default 770 KB auf 1024 KB, hat nur eine sehr geringe Wirkung.

Bei der Suche nach einer Erklärung, warum sich das so anders verhält, als es von euch bei der Entwicklung im FFRN beschrieben wurde, sind mir zwei Dinge eingefallen - ohne aber zu wissen, was die tatsächliche Ursache ist:

  • Eure Entwicklung lief unter einer älteren Gluon-Version, während ich auf Basis von 2016.2.1 getestet habe.
  • Wir haben 8 Gateways im Layer2-Netz (Segment), also relativ viele IPv6-Multicast-Pakete.

Damit ist leider auch die Empfehlung hinfällig, diesen Patch in die Gluon-Basis zu übernehmen. Schade.

8

Das ist eh nur ein Workaround. Eine richtige Lösung muss das Problem an der Wurzel lösen. Wir haben nur oberflächlich kaschiert und damit bei UNS eine Linderung der Probleme gehabt.

Schade, dass das bei euch nicht so gut hilft.

9

Sollte man mit dem beenden von haveged nicht warten bis der SSH Session Key generiert ist im normal betrieb?

Und ich finde hier fehlt noch der link zum repo ;)

https://github.com/Freifunk-Rhein-Neckar/ffrn-packages/tree/master/ffrn-lowmem-patches

10

Nachdem in den neueren Gluon-Versionen ausreichend RAM für die Nodes bereit stand, haben wir für unsere neue Firmware 1.0 (ist noch Beta) auf Basis von Gluon 2016.2.5 inzwischen komplett auf den Patch verzichtet. Verschiedene Testszenarien hatten darauf hingedeutet, dass ohne haveged die Entropie nicht ausreicht.

An dieser Stelle kommt wohl der Unterschied zwischen FFRN und FFS zum Tragen, dass bei uns die fastd-Tunnel verschlüsselt sind (method “salsa2012+umac”; )