Heute früh, noch bevor ich überhaupt richtig wach war, einmal per SSH auf donau2space – draußen in Passau alles grau gedämpft bei 8,3 °C, und im Terminal dieses beruhigende Gegenteil: htop voll, Lüfterprofil langweilig, keine Warnfarben. So ein Setup fühlt sich an wie ein Metronom: nicht spektakulär, aber exakt.
Serverstatus & Telemetrie
Der Zeitraum läuft von Mittwoch, 18. März 2026, 8:00 Uhr bis Mittwoch, 25. März 2026, 7:00 Uhr. Uptime am Ende: 1.216,28 h. Das ist für mich jedes Mal ein kleiner Vertrauensbeweis: Dauerlast, aber kein „irgendwas hat sich aufgehängt und rebootet“.
Die Woche war vom Profil her ziemlich klar:
- CPU Ø 35,9 W bei 99,9 % Usage. Heißt: praktisch durchgehend Vollauslastung, aber der Verbrauch bleibt in einem Rahmen, der nach „sauberer, gleichmäßiger Workload“ aussieht – nicht nach wildem Throttle/Gegenregeln.
- Ø 66,2 °C CPU-Temperatur. Für 24/7-Crunching ist das stabil und entspannt. Nicht „kalt“, aber weit weg von allem, wo ich nervös würde.
- Load1 8,35 bei 8 Threads: das fühlt sich einfach richtig an. Runqueue ist voll, CPU hat immer was zu tun, aber es wirkt nicht wie ein überfüllter Stau.
Beim Speicher war’s ebenfalls angenehm unkritisch:
- RAM Ø 18,4 GB (29,4 %) und Swap 0 MB. Diese Swap-Null ist für mich immer das beste Zeichen: selbst wenn Projekte mal RAM-lastig sind, bleibt genug Headroom, ohne dass der Kernel anfängt, sich mit Paging selbst zu bremsen.
- Storage ist quasi ein Non-Issue: 201,1 GB total, 173,7 GB frei. BOINC nutzt 3.498,29 MB – völlig okay, vor allem weil Einstein bei den Projekten oft gerne mal Platz belegt.
BOINC-seitig ist die Woche fast schon „zu sauber“: 2.093 Jobs erfolgreich, 0 failed. Und ja: 0 Failed Jobs macht mich deutlich glücklicher als jedes Credit-Feuerwerk, weil’s heißt, dass die ganze Last auch wirklich als verwertbares Ergebnis rausfällt.
Einziger kleiner Kratzer: 2 RPC-Failures, und die hängen komplett bei climateprediction.net (Credit/Runtime dort weiterhin 0). Das wirkt nicht wie Rechenstress, eher wie „Projekt antwortet gerade nicht sauber“.
Projekte im Detail
In der Mischung merkt man diese Woche richtig schön den Charakter der Projekte: Einstein@Home ist der schwere Langläufer (und RAM ist da nicht nur Deko), während spacious@home und PrimeGrid eher die „Rotation“ und CPU-Kante liefern. Asteroids@home läuft als leichter, kurzer Konterpart mit.
Einstein@Home – lange WUs, RAM als echter Faktor
Einstein@Home ist in meinem Setup klar der dicke Motor: 1.406.079 Credit bei expavg 33.292,12. Das dominiert nicht nur die Statistik, das merkt man auch am Systemgefühl.
Was bei Einstein auffällt: die Tasks sind nicht nur lang, sie haben teils richtig fette Working Sets. In den aktiven Tasks sehe ich 2.343 MB bis hoch zu 4.506 MB pro Task. Wenn davon mehrere parallel laufen, ist das nicht mehr „RAM ist genug da“, sondern „RAM wird aktiv benutzt“.
Technisch heißt das: mehr Speicher-Footprint → mehr Druck auf Caches/Memory-Controller → oft ein bisschen mehr Grundwärme und ein anderes Lastgefühl als bei rein CPU-bound Projekten. Die CPU steht zwar sowieso bei 99,9 %, aber wie sie diese 99,9 % füllt, macht dann den Unterschied bei Watt und Temperatur.
Und die Laufzeiten sind klassisch Einstein: zuletzt wurden 2 Tasks mit im Schnitt 44h 55m reported. Das ist diese Sorte Workunit, bei der der BOINC-Scheduler kaum Hektik hat: wenig Report/Fetch, dafür sehr lange „still durchkauen“. Für Stabilität super – solange RAM und Kühlung passen (und hier passt beides).
spacious@home – kurze Rotation, klein im RAM, macht das System lebendig
spacious@home steht bei 59.796,263753 Credit und expavg 1.294,09. Bei den zuletzt erledigten Tasks sieht man den Charakter perfekt: 14 Tasks mit Ø 46m 17s.
Das ist die Art Projekt, die sich „busy“ anfühlt, ohne schwer zu sein: schnellere Turnover, mehr Scheduler-Aktivität (reporten, neue WUs holen), aber RAM-seitig eher harmlos. In den aktiven spacious-Tasks liegen die Working Sets bei 4 MB bis 27 MB – das ist im Vergleich zu Einstein praktisch Luft.
CPU-bound genug, um die Threads sauber zu füllen, aber nicht der Typ, der dir plötzlich den RAM zudreht.
PrimeGrid – CPU-bound, teilweise kurz, teilweise zäh
PrimeGrid: 239.841,392662 Credit, expavg 4.527,24, und insgesamt 439 Jobs erfolgreich.
In den zuletzt erledigten Tasks taucht PrimeGrid diese Woche eher als „Snack“ auf: 3 Tasks mit Ø 27m 22s. Gleichzeitig läuft aber gerade ein PrimeGrid-Task, der schon 25h 58m CPU-Zeit hat und bei 44,3 % steht – also: nicht alles bei PrimeGrid ist kurz, je nach Subprojekt kann das auch ein richtiger Klotz sein.
RAM-technisch liegt der aktive PrimeGrid-Task bei 284 MB Working Set. Das ist deutlich über spacious, aber weit weg von Einstein. Also ziemlich klar: CPU-lastig, aber nicht RAM-dominant.
Asteroids@home – klein, schnell, aber gerade „organisatorisch“ auffällig
Asteroids@home steht bei 37.417,685891 Credit, expavg 731,16, mit 632 erfolgreichen Jobs.
Bei den zuletzt erledigten Tasks war’s nur 1 Task mit 1h 12m – klassisch eher kurz.
Was mir in der aktiven Liste ins Auge springt: 14 Asteroids-Tasks stehen auf UNINITIALIZED (ein Teil davon als READYTOREPORT). Das fühlt sich nicht nach Rechenproblem an, eher nach „BOINC hat hier gerade mehr Verwaltungs-/Zustandskram als echte Laufzeit“. Thermisch ist das langweilig, aber scheduler-/kommunikationsseitig interessant: Rechnen ist nicht der einzige Teil der Pipeline.
Auffälligkeiten
Die Woche hatte keine Temperatur-Drosselung und auch keine Flags – also keine „Alarmkanten“. Aber zwei Momente waren trotzdem charakteristisch.
Erstens der Temperatur-Ausreißer: 74 °C am Samstag, 22. März 2026, 11:00 Uhr. Wenn ich sowas sehe, denke ich nicht „oh nein“, sondern automatisch: Was war da gerade für ein Mix? Weil der Schnitt bei 66,2 °C liegt, sind 74 °C eben kein Dauerzustand, sondern ein Moment.
Plausibel ist hier: mehrere RAM-schwere Einstein-WUs gleichzeitig in einer Phase, wo sie wenig Stalls haben und die CPU „dichter“ arbeitet. Gleiche 99,9 % Auslastung – aber mehr echte Arbeit pro Zeit → mehr Wärme.
Zweitens der Watt-Peak: 44 W am Samstag, 22. März 2026, 13:00 Uhr. Auch hier: nicht dramatisch, aber im Verhältnis zu Ø 35,9 W ein klarer Sprung. Watt-Spikes sind bei mir fast immer ein Hinweis auf Instruktionsmix/Workunit-Wechsel: manche WUs treiben die CPU intern einfach effizienter/härter, obwohl die Auslastung sowieso schon am Anschlag klebt.
Was ich an beiden Peaks mag: sie bleiben Peaks. Kein Throttle, kein Swap, keine Errors. Das wirkt „souverän“.
Fazit
Unterm Strich war das eine stabile, stoische Cruncher-Woche: 99,9 % CPU-Usage, Load1 8,35 genau da, wo er bei 8 Threads hingehört, Swap 0 MB, und 2.093 erfolgreiche Jobs bei 0 Failures.
Einstein@Home bleibt der schwere Brocken mit mehreren GB RAM pro Task und richtig langen Laufzeiten. spacious@home macht die Rotation und hält das Ganze lebendig, ohne den Speicher zu stressen. PrimeGrid pendelt zwischen „kurz wegrotieren“ und „lang kauen“, und Asteroids@home ist gerade eher im „Zustands-/Report“-Modus auffällig.
Und ja: so eine Woche ist fast schon frech unspektakulär. Aber dann sehe ich wieder die 0 Failed Jobs und denke mir: genau so soll 24/7-Last aussehen. Draußen alles auf Leise, drinnen rechnet’s einfach weiter 😎
Diagramme
Begriffe kurz erklärt
- SSH: SSH ist ein sicheres Protokoll, um sich verschlüsselt per Kommandozeile auf entfernte Rechner einzuloggen.
- BOINC: BOINC ist eine Plattform, mit der viele Computer freiwillig Rechenleistung für wissenschaftliche Projekte bereitstellen.
- RPC-Failure: Ein RPC-Failure bedeutet, dass ein Programmaufruf über das Netzwerk nicht erfolgreich beim Ziel-Rechner ankommt oder keine Antwort bekommt.
- Workunit: Eine Workunit ist ein kleiner Aufgabenblock, den verteilte Systeme wie BOINC an Teilnehmer zum Rechnen schicken.
- Working Set: Das Working Set beschreibt den Teil des Speichers, den ein Programm aktuell häufig nutzt.
- Scheduler-Aktivität: Die Scheduler-Aktivität zeigt, wie das System Prozesse auf verfügbare CPU-Kerne verteilt.
- Runqueue: Die Runqueue ist eine Warteschlange mit Prozessen, die gerade darauf warten, auf der CPU ausgeführt zu werden.
- Memory-Controller: Der Memory-Controller regelt, wie Daten zwischen Arbeitsspeicher und Prozessor transportiert werden.
- CPU-bound: CPU-bound beschreibt Programme, die hauptsächlich von der Rechenleistung der CPU und weniger von Speicher oder Festplatte abhängen.
- Throttle/Gegenregeln: Throttle oder Gegenregeln meint, dass ein System absichtlich Leistung reduziert, um Überhitzung oder Überlast zu verhindern.
- Paging: Paging bedeutet, dass das Betriebssystem Speicher in kleine Blöcke (Seiten) aufteilt und sie bei Bedarf zwischen RAM und Festplatte austauscht.
- Swap: Swap ist der Festplattenbereich, in den selten genutzte Speicherinhalte ausgelagert werden, wenn der Arbeitsspeicher knapp wird.
- Telemetrie: Telemetrie ist das automatische Sammeln und Übertragen von Messdaten, etwa über Temperatur, Position oder Systemauslastung.
