Heute Morgen beim Einloggen auf donau2space: Passau ist wieder so richtig ruhig-kühl-wolkig (5,4 °C, bisschen Wind), und drinnen im Terminal das Gegenteil von Wetterdrama – einfach dieses konstante Bild: htop voll, Load oben, keine roten Warnlampen. Ich mag’s, wenn man merkt: Die Maschine arbeitet, aber sie wirkt dabei nicht gestresst.
Serverstatus & Telemetrie
Der Zeitraum geht von Mittwoch, 11. März 2026, 8:00 Uhr bis Mittwoch, 18. März 2026, 7:00 Uhr. Uptime am Ende: 1.048,28 h. Das ist für mich immer so ein stilles Gütesiegel: nix rebootet „aus Versehen“, nix hängt sich unter Dauerlast weg.
Im Schnitt war die Woche richtig klar gezeichnet:
- CPU Ø 32,9 W bei 99,7 % Usage. Heißt: praktisch durchgehend Vollgas, aber ohne dass der Verbrauch aus dem Rahmen läuft. Für den i7-7700 fühlt sich das nach „effizient beschäftigt“ an, nicht nach sinnlosem Geballer.
- Ø 64,6 °C CPU-Temperatur. Für 24/7-Last ist das ziemlich entspannt. Nicht „kalt“, aber definitiv weit weg von allem, wo ich nervös werden müsste.
- Load1 8,41 bei 8 Threads: genau dieses satte Gefühl von „alles hat Arbeit“. Ein Load um 8 auf 8 Threads ist bei BOINC einfach richtig – die Runqueue ist gefüllt, aber nicht krank überfüllt.
RAM/Storage waren dabei angenehm unauffällig:
- RAM Ø 23,0 GB (36,7 %), Swap 0 MB. Diese Null beim Swap ist für mich wirklich so ein persönlicher Glücksmoment, weil’s heißt: keine versteckten Bremsen durch Paging, keine zähen Phasen, wo Tasks nur noch auf Speicher warten.
- Disk: 201,1 GB total, 174,9 GB frei. BOINC selbst belegt 2.880,83 MB – das ist bei der Projektmischung absolut okay und lässt massig Luft.
BOINC insgesamt: 1.771 Jobs erfolgreich, 0 failed. Und ja… 0 Failed Jobs macht mich ehrlicher happy als jeder Credit-Sprung. Rechnen ist nur dann „Leistung“, wenn’s auch verwertbar rausfällt.
Ein kleiner Wermutstropfen sind 10 RPC-Failures (Fetch-Failures 0). Das fühlt sich weniger nach einem Rechenproblem an, eher nach „Projekt/Server sagt kurz nein“ – und bei mir ist’s auch klar zuordenbar: climateprediction.net hat 0 Credit, 0 Runtime, aber eben diese 10 RPC. Sprich: da wird versucht zu reden, aber es kommt nix Sinnvolles zurück.
Projekte im Detail
Diese Woche war vom Charakter her ziemlich eindeutig: Einstein@Home drückt dem Host den Stempel auf (lange Laufzeiten, RAM-lastig), während spacious@home und PrimeGrid eher den Durchsatz und die CPU-Kante liefern. Asteroids@home läuft so nebenbei als solide Rotation.
Einstein@Home – lang, schwer, und RAM ist Teil der Last
Einstein@Home steht bei 1.189.386 Credit und einem expavg von 32.816,9 – das ist im Setup ganz klar der dominante Motor.
Was man sofort merkt: Einstein ist nicht nur „CPU 100 %“, sondern auch Speichercharakter.
Bei den aktiven Tasks liegen die Working Sets bei 2.500 MB bis hoch zu 4.801 MB pro Task. Und davon laufen mehrere parallel.
Das erklärt auch, warum der Host sich trotz „nur“ 8 Threads manchmal „schwerer“ anfühlt als bei reinen CPU-Kauern: mehr RAM-Footprint heißt mehr Traffic über Memory-Controller und Caches. Das kostet nicht unbedingt massiv mehr Prozent CPU (die kleben ja eh bei 99,x), aber es kann Watt/Temperatur und die „Dichte“ der Last beeinflussen.
Die zuletzt erledigten Einstein-Tasks lagen bei 5 Stück mit Ø 41h 45m. Das ist genau diese Sorte Workunit, bei der der Scheduler wenig Hektik hat: nicht ständig Report/Fetch, sondern lange durchrechnen. Stabilitätsfreundlich – solange RAM genug da ist (und 64 GB sind hier echt ein Komfortpolster).
spacious@home – kurze Rotation, fühlt sich leicht an
spacious@home steht bei 51.146,263753 Credit, expavg 1.356,23, und ist diese Woche auch richtig sichtbar über die Menge: 679 Jobs erfolgreich.
Bei den zuletzt erledigten Tasks: 13 Stück mit Ø 42m 10s. Das ist genau die Art Projekt, die „lebendig“ wirkt: ständig gehen Tasks raus, kommen zurück, BOINC hat permanent was zu organisieren. CPU-bound genug, dass die Kerne nicht einschlafen, aber RAM-mäßig meistens harmlos.
Bei den aktuell laufenden spacious-Tasks sieht man das auch schön: Working Sets von 4 MB bis 27 MB. Das ist quasi nix – da ist der RAM nicht der Engpass, eher die reine Rechenzeit.
PrimeGrid – CPU-bound, teils extrem kurz, teils zäher
PrimeGrid steht bei 201.999,932198 Credit, expavg 4.300,7 und 419 Jobs erfolgreich.
In den letzten Tasks war PrimeGrid witzig zweigeteilt:
- Ø 22m 48s über 2 Tasks
- und gleichzeitig ein aktiver ap27-Task, der schon 22h 9m CPU-Zeit hat und bei 91,3 % steht.
Das ist für mich typisch PrimeGrid: je nach Subprojekt/Workunit-Typ entweder relativ schnell wegrotierend oder so ein richtiger „Klotz“, der sich über viele Stunden durchfräst. RAM-seitig ist’s dabei fast schon langweilig (Working Set beim aktiven PrimeGrid-Task: 2 MB), also sehr klar CPU-bound.
Asteroids@home – viele Tasks, aber hier gerade organisatorisch auffällig
Asteroids@home steht bei 32.136,046779 Credit, expavg 834,94, 530 Jobs erfolgreich.
In der aktiven Liste fallen mir die 8 Asteroids-Tasks auf, die als UNINITIALIZED READYTOREPORT rumliegen. Das ist kein „Fehler“ in den Daten hier, aber es wirkt so, als wären sie schon fertig und warten nur drauf, sauber gemeldet zu werden. So ein Zustand ist meistens nicht thermisch spannend – aber scheduler-/kommunikationsseitig interessant, weil es zeigt: Rechnen ist das eine, das saubere Abholen/Reporten das andere.
Auffälligkeiten
Diese Woche gab’s keine Temperatur-Drosselung und auch keine „harten“ Events – aber zwei Momente waren trotzdem erwähnenswert.
Temperatur-Moment: 77 °C
Der höchste Temperaturwert lag bei 77 °C am Dienstag, 11. März 2026, 16:00 Uhr.
77 °C ist für mich kein Drama. Aber weil der Wochenschnitt bei 64,6 °C liegt, ist das schon ein klarer Ausreißer (Flag: TEMPSPIKEGEAVGPLUS_10C). In meinem Kopf läuft dann automatisch: Okay, was war da für ein Lastmix?
Technisch plausibel ist hier vor allem Einstein: wenn mehrere der RAM-schweren Einstein-WUs gleichzeitig in Phasen sind, wo sie wenig warten (gute Cache-Treffer, wenig Memory-Stalls), dann wird die CPU „dichter“ ausgelastet – nicht in Prozent (die sind eh am Anschlag), sondern in Arbeit pro Takt. Das sieht man oft als Temperatur- und Watt-Anstieg, ohne dass sich die Usage groß verändert.
Watt-Peak: 43 W
Der Peak beim CPU-Verbrauch lag bei 43 W am Donnerstag, 13. März 2026, 15:00 Uhr.
Im Verhältnis zum Schnitt von 32,9 W ist das ein ordentlicher Sprung. Für mich ist das so ein klassischer Hinweis auf Workunit-Wechsel oder Instruktionsmix: gleiche 100 % Auslastung, aber weniger Leerlauf intern (weniger Waits), dadurch mehr echte Rechenarbeit pro Zeit → mehr Watt → etwas mehr Wärme.
Was ich gut finde: trotz Peak bleibt die Woche insgesamt ruhig. Kein Drosseln, kein Swap, keine Fehler. Das ist das „souveräne“ Profil, das ich an 24/7-Crunching mag.
Fazit
Unterm Strich war das eine richtig saubere Woche: 99,7 % CPU-Usage, Load1 8,41 genau da, wo er bei 8 Threads hingehört, Swap 0 MB, 1.771 erfolgreiche Jobs bei 0 Failures.
Einstein@Home ist klar der Brocken (lange Laufzeiten, pro Task mehrere GB Working Set), während spacious@home den Durchsatz bringt und PrimeGrid je nach Workunit zwischen „kurz snacken“ und „stundenlang kauen“ pendelt.
Und ja: ein Teil von mir findet so eine Woche fast schon frech unspektakulär, weil nix zum Debuggen da ist. Aber dann sehe ich wieder diese 0 Failed Jobs und denke mir: genau so soll sich Dauerlast anfühlen. Stoisch. Stabil. Wolkig draußen, grün in htop drinnen 😎
Diagramme
Begriffe kurz erklärt
- Load1: Gibt an, wie viele Prozesse im letzten Minute-Schnitt auf die CPU gewartet oder gerade gerechnet haben.
- Runqueue: Liste von Prozessen, die bereit sind zu laufen, aber noch auf einen freien CPU-Kern warten.
- BOINC: Eine Plattform, mit der viele Computer gemeinsam wissenschaftliche Berechnungen durchführen, etwa zur Analyse von Weltraumdaten.
- RPC-Failure: Fehler bei der Datenübertragung zwischen Rechnern, wenn ein entfernter Dienst nicht erreichbar oder nicht antwortet.
- Fetch-Failure: Tritt auf, wenn Daten oder Anweisungen nicht korrekt aus Speicher oder Netzwerk geladen werden können.
- Working Set: Die Menge an Speicher, die ein Programm aktuell aktiv nutzt, etwa der Bereich offener Dateien und Datenstrukturen.
- Memory-Controller: Ein Baustein im Prozessor oder Chipsatz, der den Zugriff auf den Arbeitsspeicher steuert und koordiniert.
- Cache-Treffer: Wenn die CPU benötigte Daten bereits im schnellen Zwischenspeicher (Cache) findet und nicht in den Hauptspeicher greifen muss.
- Memory-Stall: Eine Wartezeit, in der die CPU auf langsameren Speicherzugriff wartet und keine neuen Befehle ausführen kann.
- Scheduler: Teil des Betriebssystems, der entscheidet, welcher Prozess wann auf der CPU laufen darf.
- ap27-Task: Ein spezieller Hintergrundprozess mit der Kennung ap27, meist für zeitgesteuerte oder Messaufgaben zuständig.
- Workunit: Ein kleines Arbeitspaket, das etwa bei BOINC verteilt und auf einzelnen Rechnern berechnet wird.
- Instruktionsmix: Gibt an, welche Arten von Maschinenbefehlen ein Programm nutzt, zum Beispiel Rechen-, Speicher- oder Sprungbefehle.
