Kalmar und das Virus

ARM64-Cluster unter den Bedingungen von Covid19

Motivation

Im Jahre 2020 hinterließ das Virus Sars-CoV-2 einen gewissen Eindruck: Viele Menschen erkrankten, viele starben, und damit nicht so viele Menschen sterben, wurde das öffentliche Leben beschränkt. Kontaktsperre oder modischer, kürzer und griffiger „Social Distancing“.

Als Miterleber dieser Situation hatte man einige Handlungsoptionen:

1. Klopapier hamstern
2. Gesichtsmasken nähen
3. Nichts tun
4. Irgendie wissenschafteln

Zumindest für das hamstern von Klopapier war ich zu spät, zum Nähen von Gesichtsmasken zu faul, nichts tun wollte ich auch nicht, also falte ich ein paar Eiweiße. Bei Folding@home gab es etwas zum Thema Covid-19. Da ich früher schon mal da mitgemacht hatte, habe ich mich einfach wieder daran gesetzt. Allerdings hat sich da der Fokus in den letzten Jahren verschoben, Folding@home ist jetzt hauptsächlich für GPUs gemacht, wo auch sparsame 100-Euro-Modelle so schnell falten wie die teuersten und energiehungrigsten CPUs. Außerdem musste ich festellen, dass man tagelang auf Workunits warten musste. Also etwas anderes. Es gibt da Rosetta@home, das unter BOINC läuft. Auf dem PC schnell per apt installiert, Projekt auswählen, läuft.

Nachdem das so ein paar Tage lief, gab es am 2.4.2020 die Meldung, dass Rosetta@home jetzt auch für ARM64 portiert ist. Und da kommt der Kalmar ins Spiel. Ausstattungsstand des Kalmars zu dem Zeitpunkt: 8xOdroid C2 und 1xRock64. Eine gewisse Modernisierung ist bis hierher nicht ausgeschlossen, sollte es nötig sein.

SBC-Vergleich

Übersicht über verschiedenen Einplatinenrechner

Odroid C2

Es geht los mit einem neuen Image: Armbian für Odroid C2. Allgemeine Informationen, wie man mit Armbian umgeht, finden sich hier.

• SSH geht sofort
• BOINC ist auch im apt-Repository
• X-Forwarding in /etc/ssh/sshd.config einschalten
• Der Benutzer muss in die Gruppe boinc hinzugefügt werden
• boincmgr starten

Aber ach, es gibt die Meldung:

Rosetta@home: Notice from server Rosetta for Portable Devices needs 1907.35 MB RAM but only 1770.35 MB is available for use.

OK, wir brauchen also 140 MB mehr freien RAM. Wie wir weiter unten sehen werden, lohnt es sich aber nicht, dem Speicher hinterherzujagen. Also Thema Odroid C2 erst mal abgehakt. Schade eigentlich, denn davon habe ich 8 Stück.

Update 10.08.2020

Nachdem ich zufällig in der CPU-Liste der Projektseite von Rosetta@home rumgestöbert habe, habe ich entdeckt, dass inzwischen mehrere Odroid C2 dort aufgeführt sind. Daher habe ich wieder einen C2 rausgeholt und es wieder probiert. Diesmal wird weniger Speicher gebraucht. Das ist mir in den letzten Wochen schon aufgefallen, da ich die Meldung „waiting for memory“ nicht mehr gesehen habe. Damit kann ich den Kalmar also noch um einige bereits vorhandenen Odroiden erweitern. Allerdings habe ich auf der Rosetta@home-Benutzerseite gesehen, dass sehr viele Workunits des C2 mit „validate error“ ausfgeführt sind. Ich verringere die Anzahl der zu nutzendem CPU-Kerne in den Einstellungen auf 3. Dadurch werden diese Fehler deutlich seltener, aber sie treten immer noch auf.

Nach einem Monat Laufzeit erreicht der C2 einen Boinc-Average von 335. Das ist etwa ein drittel eines Rasperry Pi 4 oder die Hälfte eines Rock64. Hier spielt das Verdrängen aus dem Speicher eine große Rolle: Sehr häufig läuft nur ein einziger Prozess.

Rock64

Der Rock64 hat 4 GB RAM. Zwar ist der Prozessor etwas langsamer, aber mal sehen. Durch die guten Erfahrungen mit Armbian beim Odroid C2 entscheide ich mich für den Rock64 ebenfalls dafür. Das Image findet man hier. Das Vorgehen ist das gleiche wie beim Odroid C2:

• SSH geht sofort
• BOINC ist auch im apt-Repository
• X-Forwarding in /etc/ssh/sshd.config einschalten
• Der Benutzer muss in die Gruppe boinc hinzugefügt werden
• boincmgr starten

Projekt auswählen klappt ohne Probleme, Aufgaben werden runtergeladen, läuft:

Auffällig ist, dass nach einer Weile der Speicher knapp wird. Haben die 4 Prozesse ungefähr 60% erreicht, dann wird einer angehalten mit der Meldung

Waiting for memory.

Ich werde den Kalmar aber nicht mit noch mehr Rock64-SBCs ausstatten, denn die Spannungsversorgung wäre einfacher, wenn man auf die vorhandenen USB-Netzteile zurückgreifen könnte. Es gibt ja noch mehr Rechnertypen.

Raspberry Pi 4

Spannungsversorgung hier ist über USB-C. Das kommt mir entgegen, denn auf dem Kalmar sind 2 USB-Netzteile mit jeweils 5 Ausgängen vorhanden. Ein fertiges Armbian-Image gibt es dafür nicht. Raspian ist nur 32-Bittig verfügbar, wir brauchen für Rosetta@home aber ein 64-Bit-System. Es gibt eine Anleitung, wie man ARM64-Debian auf den Raspberry Pi 4 bekommt. Damit ist man eine Weile beschäftigt, aber am Ende hat man ein Standard-Debian drauf. Das ist im Prinzip das, was alle immer wollten. Damit ist auch BOINC in den Paketquellen verfügbar. Installation und Start also genau so einfach wie auf dem PC.

Ab da läuft es wie auf dem Rock64, ebenfalls lässt sich hier nach einer Weile beobachten, dass ein Prozess aus Speichermangel angehalten wird.

Da der Raspberry Pi 4 standardmäßig ohne Kühler ausgeliefert wird, passiert es, dass der Prozessor den Takt absenkt, wenn die Temperatur zu hoch ist. In Verbindung mit der Beobachtung, dass sich die Rosetta@home-Prozesse mitunter aus Speichermangel gegenseitig verdrängen, stellt sich die Frage, wie sich die Ergebnisleistung für die Fälle 3/4 Prozesse und mit/ohne Kühler unterscheiden. Es werden verschiedene Kühler verwendet: Einmal als Satz aus RPI COOL 4SXI und RPI COOL 40X30 (künftig bezeichnet als Kühlersatz) und andererseits das massive Gehäuse RPI CASE ALU07. Der Kühlersatz ist anders kombiniert als vom Hersteller vorgesehen: Raspberry Pi 4 mit Külersatz wurden liegend betrieben, mit dem ALU07-Kühler hingegen stehen. Dies ist immer mal wieder als Empfehlung zu lesen, da die Konvektion dann auf beiden Seiten wirkt. Zur Bestimmung der Messwerte siehe Abschnitt "Messwerte".

*: Nur BOINC-Average bestimmt

Wie man leicht sieht, hat die Wahl 3 oder 4 Prozesse einen größeren Effekt als die Wahl der Kühlung, die man schon als statistisch nicht signifikant bezeichnen kann. Den Messwerten nach liefen durchschnittlich 3,69 Prozesse, wenn man sich auf 4 Prozesse festgelegt hat, und man annimmt, dass bei 3 Prozessen im Durchschnitt keine Verdrängung stattfindet.

RockPi-4A

Eine weitere Variable soll noch untersucht werden: das Big.LITTLE-Prinzip. Als Vertreter dieser Fraktion bietet sich ein RK3399-basierter SBC an. Die Wahl fällt auf den RockPi-4A, als Betriebssystem kommt wieder armbian zum Einsatz: Das Image wird genau so behandelt wie beim Rock64 oder beim Odroid C2, auch die folgende Verwendung ist gleich.

Da der RockPi-4A nur über 2 große Kerne verfügt, diese aber schneller als jene des RaspberryPi 4 sind, und dazu über 4 kleine Kerne, ist es interessant, welcher Effekt - verdrängen aus dem Speicher, laufen auf den schnellen oder den langsamen Kernen- überwiegt. Getestet wird mit 4 oder 5 Prozessen. Die SBCs verfügen über einen recht stabil aussehenen Kühlkörper von Allnet für etwa 10 Euro und werden auf der Seite stehend betrieben.

Leider fielen die beiden Exemplare erst alle paar Tage, später dann alle paar Stunden aus. Dauerlastfähig scheinen die also nicht zu sein. Der errechnete BOINC-average enthält damit auch viele solcher Fehlzeiten. Inwieweit die Unterschiede zwischen 4 und 5 Prozessen hier auf verschiedene Fehlzeiten oder tatsächlich auf Eigenheiten des Schedulings zurückzuführen sind, lässt sich nicht sagen.

Vergleich mit einem PC

Natürlich interessiert hier auch, wie sich das ARM-Cluster gegen einen PC schlägt. Daher habe ich noch einmal den AMD FX-8320 bemüht, der auch schon beim alten Kalmar als Vergleich herhalten durfte. Dieser PC ist inzwischen recht überholt, möglicherweise werde ich ihn beim nächsten Versuch durch einen moderneren ersetzt haben. Wie sich verschiedene PCs untereinander ausnehmen, kann sicherlich anderswo nachgelesen werden.

Da der Energiebedarf und die Lärmentwicklung des PCs ausgesprochen hoch ist, wurde dafür kein BOINC-Average bestimmt. Möglicherweise hole ich das im Winter nach, wenn die Rechnerabwärme noch einen nutzbringenden Nebeneffekt hat.

Schlussfolgerungen

Speicherknappheit

Es sieht so aus, als würde mit der Zeit mehr Speicher verbraucht werden. Daran kann man erkennen, dass es wahrscheinlich nichts bringen würde, auf dem Odroid C2 noch ein bisschen Speicher freizuschaufeln. Nach kurzer Zeit wäre der wieder voll und die Prozesse würden sich gegenseitig behindern. Vielleicht könnte man es schaffen, von vornherein mit nur einem Prozess zu starten, aber wir haben 4 ARM-Kerne an Board.

Geschwindigkeitsunterschiede

Bevor Workunits heruntergeladen werden, wird ein Benchmark ausgeführt. Die Workunits werden auf die Geschwindigkeit des Rechners zugeschnitten, denn auf den verschiedenen SBCs und auch auf dem PC laufen die einzelnen Teile immer so etwa 8 Stunden.

Energiebedarf

Nicht außer acht gelassen werden darf der Energiebedarf. Immerhin laufen die Rechner unter Vollast. Ich verwende ein Energiekostenmessgerät von Typ Brennenstuhl PM 230, mit dem der PC und der gesamte Kalmar ausgemessen wird.

Gemessen wird die gesamte Energieaufnahme über 24 Stunden.

Messwerte

Um zu bestimmen, wieviel Faltung ein Rechner denn nun schafft, kann man auf der Rosetta@home-Seite unter seinem Benutzerstatus schauen. Dort sind alle Rechner aufgelistet, samt der „Wissenschaftsmenge“, welche sie vollbracht haben. Diese ist in der Einheit „Credit“ angegeben, zusätzlich ist für jede Workunit die benötigte Gesamtzeit und die benötigte CPU-Zeit angegeben. Die interessante Zeit hier ist die Gesamtzeit der Workunit. Es wird der Durchschnitt über die letzten 32 Workunits berechnet. Da die Werte sehr stark schwanken, werden für jeden Rechner die schnellsten und die langsamsten beiden Werte entfernt, sodass sich der Durchschnitt letztlich auf 28 Werte stützt. Es wurde für alle Rechner mit der Anwendung Rosetta 4.20 getestet. Als Vergleichseinheit wird mC/s (Millicredits/Sekunde) für die Einzelkerne und Knoten verwendet, die Tagesleistung eines Knotens und der Tagesenergiebedarf werden über 24 Stunden betrachtet. Wer an einer möglichst hohen Wissenschaftsleistung interessiert ist, den interessiert in erster Linie die Tagesleistung eines Knotens, wer das ganze möglichst sparsam haben möchte, den interessiert die Spalte Credits/Wh.

Zuverlässigkeit der Messwerte

Ich habe beobachtet, dass auf eine Reihe von Workunits, die jeweils mit über 200 Punkten bewertet wurden, einige Tage lang welche folgten, die nur um die 40 Punkte erreichten. Messwerte, die über 28 oder 32 aufeinanderfolgende Arbeitspakete gebildet werden, haben also keine Aussagekraft. Es gibt im BOINC-Punktesystem den Wert „Average Credits“. Über einen längeren Zeitraum gebildet, sollte dieser Wert aussagekräftig sein. Daher wurden die Average-Werte über einen Monat gebildet und ergänzend angefügt. Dieser BOINC-Average sollte in etwa der Tagesleistung eines Knotens entsprechen.

Leider schwankt auch dieser Average sehr stark, beispielsweise lag der anfangs beim Rock64 bei etwa 1100 und fiel später auf unter 500 ab, stieg über die Wochen aber langsam wieder an. Letztlich kann man also diesen BOINC-Average zwischen den einzelnen Rechnern nur vergleichen, wenn er zeitgleich bestimmt wurde.

Ergebnisse gesamt

Es ergibt sich folgendes Bild:

*: 4 Prozesse, mit Kühlersatz

**: 5 Prozesse

***: Knoten ist der gesamte Kalmar, hochgerechnet aus dem Endausbau

Im Endausbau besteht der Kalmar aus folgenden SBC:

• 1x Rock 64
• 8x Raspberry Pi 4 mit Kühlersatz

Da die RockPi-4A durch häufiges Ausfallen auffielen, haben sie keinen dauerhaften Einzug in den Kalmar geschafft. Außerdem wurden für die Energiemessung alle weiteren Komponenten mit beachtet, indem einfach alle Netzteile für die SBCs sowie für den Netzwerkswitch in eine gemeinsame Steckerleiste gesteckt wurden und vor der Steckerleiste gemessen wurde.

Ausblick

Inzwischen ist der RaspberryPi4 mit 8 GB RAM aufgetaucht, sicherlich werden noch weitere SBC dieser Ausstattung folgen. Damit erübrigt sich das gegenseitige Verdrängen aus dem RAM (sofern die Rosetta-Prozesse nicht größer werden), und mehr Augenmerk kann auf die CPU-Leistung gelegt werden.

Es bleibt spannend!