Heute beim Einloggen war’s so ein klassischer „erst Passau, dann Payload“-Moment: draußen meist klar, so um die 15,0 °C, quasi kein Wind – und drinnen auf donau2space wieder dieses beruhigende Bild: htop auf, acht Threads voll, nichts zappelt, nichts schreit. Einfach Arbeit, konstant.
Schneller Überblick
Zusammenfassung
Der Bericht gibt einen Wochenüberblick über den Betrieb des Rechners donau2space im Zeitraum 29.04.–06.05.2026. Die Auswertung konzentriert sich auf CPU- und Speicherauslastung, Temperaturentwicklung sowie die Ausführung verschiedener BOINC-Projekte. Der Betrieb verlief stabil mit hoher Auslastung, ohne Ausfälle und mit geringen Abweichungen der Systemwerte.
Auf den Punkt
- CPU war im Schnitt zu 99,5 % ausgelastet, bei durchschnittlich 67,5 °C und 37,1 W.
- Kein einziger Task schlug fehl; 4.189 Jobs wurden erfolgreich abgeschlossen.
- RAM war durchschnittlich zu 43 % belegt (26,9 GB), Swap wurde nie genutzt.
- Einstein@Home dominierte das System mit langen Tasks (~40h) und hohem RAM-Bedarf (~5,1 GB pro Task).
- PrimeGrid erzeugte weniger, aber sehr lange und CPU-lastige Tasks (ein Task ~58h).
- spacious@home und Asteroids@home belegten kaum RAM und liefen in schnelleren Task-Rotationen.
- Keine Temperaturdrosselung oder sicherheitsrelevante Ereignisse im Laufzeitraum.
FAQ
- Wie hoch war die durchschnittliche CPU-Auslastung?
- Im Durchschnitt lag die CPU-Auslastung bei 99,5 %.
- Wurde Swap-Speicher genutzt?
- Nein, Swap wurde zu keiner Zeit verwendet.
- Welches Projekt beanspruchte am meisten RAM?
- Einstein@Home, mit etwa 5,1 GB RAM pro Task.
- Gab es Systemausfälle oder fehlgeschlagene Tasks?
- Nein, es gab 0 fehlgeschlagene Tasks und keine kritischen Systemereignisse.
Serverstatus & Telemetrie
Der Zeitraum geht von Mittwoch, 29. April 2026, 8:00 Uhr bis Mittwoch, 6. Mai 2026, 7:00 Uhr. Die Uptime steht beim letzten Wert bei 2.224,27 h. Das ist für mich immer so ein stilles Qualitätsmerkmal: nicht „wow“, sondern „läuft“ – und zwar ohne dass irgendwo heimlich was wegfault.
Im Schnitt war die Woche ziemlich eindeutig: Vollgas, aber kontrolliert.
Die CPU lag durchschnittlich bei 37,1 W und 67,5 °C bei 99,5 % Usage. Das ist genau der Bereich, den ich bei 24/7-Last am i7‑7700 gern sehe: nicht kalt (weil dann stimmt oft was mit Last/States nicht), aber auch weit weg von „thermisch am Anschlag“.
Der Load1 Ø 8,34 bei 8 Threads fühlt sich wieder „richtig“ an. Das ist dieses Bild von: alle Kerne haben zu tun, die Runqueue ist nicht leer, aber du läufst auch nicht in so eine Scheduling-Schlange rein, wo sich Tasks stapeln und du eigentlich nur Overhead produzierst.
RAM war spürbar belegt, aber ohne Druck: Ø 26,9 GB (43,0 %), Peak bei 31,82 GB (50,84 %). Und das Wichtigste dabei: Swap 0 MB. Genau das trennt für mich „viel RAM-Nutzung“ von „Problem“ – solange nichts ausgelagert wird, bleibt die Rechenleistung da, wo sie hingehört, und du fängst nicht an, Speicher über die Platte zu schieben.
Storage ist total entspannt: 201,1 GB total, 175,5 GB frei. BOINC selbst belegt 1.378,45 MB – das ist eher ein „passt in die Hosentasche“-Footprint, nichts was irgendwie knapp wirkt.
BOINC-seitig war’s einfach sauber: 4.189 Jobs succeeded, 0 failed, dazu 0 RPC failures und 0 fetch failures. Diese Null bei „failed“ ist für mich immer noch der bessere Dopamin-Hit als steigende Credits – weil das heißt: Last ja, aber keine schleichenden Fehler, keine instabilen WUs, kein Client-Gezicke.
Projekte im Detail
Vom Charakter her dominiert weiterhin ganz klar ein Projekt das Systemprofil – und die anderen geben Takt und Rotation.
Einstein@Home – RAM-lastiger Langläufer, der den Host „prägt“
Einstein ist bei 2.443.176 Credit und einem expavg von 27.592,1. Das ist nicht nur „läuft mit“, das ist das Grundrauschen.
Man sieht’s auch an den aktiven Tasks: mehrere Einstein-WUs laufen mit ~5.153 MB bis 5.177 MB Working Set pro Task. Das ist schon eine Ansage – nicht kritisch bei 64 GB RAM, aber es erklärt sofort, warum der RAM-Durchschnitt nicht bei 4–8 GB rumdümpelt.
Technisch ist das genau diese Mischung aus CPU-Last + hohem Memory-Footprint, die ich spannend finde: selbst wenn die CPU-Auslastung konstant bei ~100 % steht, kann mehr Speichertraffic (Cache/Memory-Controller) kleine Verschiebungen bei Watt und Temperatur auslösen. Nicht als Drama, eher als: „ah, das ist jetzt ein anderer Workunit-Typ/Mix“.
Auch die Laufzeiten passen zu „ruhig, aber schwer“: zuletzt erledigte Einstein-Tasks lagen bei Ø 39h 30m. Das ist schedulertechnisch angenehm: wenig Taskwechsel, wenig Reporting-Hektik, lange gleichmäßige Last – der Host kann einfach durchziehen.
PrimeGrid – CPU-bound, zäh in der Laufzeit
PrimeGrid steht bei 492.047,741363 Credit, expavg 6.621,29. Und PrimeGrid macht wieder das, was es gerne macht: nicht unbedingt viele Tasks, aber wenn einer läuft, dann richtig.
In den zuletzt erledigten Tasks war 1 PrimeGrid-Task mit 57h 51m dabei. Das ist schon so ein Brocken, wo ich innerlich immer kurz nicke: CPU-bound, wenig Schnickschnack, aber lange am Stück.
Aktiv läuft auch gerade wieder eine PrimeGrid-WU (llrSR5) mit 282 MB Working Set. Im Vergleich zu Einstein ist das RAM-seitig fast nichts – das ist genau der Unterschied: PrimeGrid drückt eher „reine Rechenarbeit“ auf die ALUs/FPUs, während Einstein zusätzlich spürbar über den Speicherpfad atmet.
spacious@home – kurze Rotation, fast unsichtbar im RAM
spacious@home ist bei 115.546,263753 Credit und expavg 1.431,35. Das fühlt sich auch in den Taskzeiten so an: zuletzt 9 Tasks mit Ø 48m 7s.
Diese kurze Rotation merkt man im Alltag: mehr „Bewegung“ im Scheduler, öfter Reports, öfter neue WUs. Ressourcenmäßig ist es hier superzahm: aktive Tasks mit 4 MB bis 27 MB Working Set. Das ist so wenig, dass es in der Gesamttelemetrie fast untergeht – aber genau deshalb ist spacious ein guter „Füller“, wenn man Kerne beschäftigt halten will, ohne RAM-Druck zu erzeugen.
Asteroids@home – moderat lange Tasks, sehr schlank
Asteroids@home steht bei 79.298,864763 Credit und expavg 1.067,76. Zuletzt waren es 7 Tasks mit Ø 1h 11m – also länger als spacious, aber weit weg von Einstein/PrimeGrid.
Das Ressourcenprofil ist angenehm leicht: ein aktiver Task liegt bei 14 MB Working Set. CPU wird gut beschäftigt, RAM ist praktisch egal.
Im aktiven Set fallen allerdings viele Einträge als UNINITIALIZED (teils READY_TO_REPORT) auf. Solange die Infrastruktur sauber bleibt – und das tut sie hier mit 0 RPC failures und 0 fetch failures – wirkt das auf mich eher wie „Client-/Statuszustand“ als wie echte Rechenprobleme. Wenn da was faul wäre, würde es sich ziemlich schnell in failed oder Retries zeigen. Tut’s nicht.
climateprediction.net – weiterhin nicht im Mix
Bleibt bei 0 Credit, 0 Jobs, 0 Runtime. Diese Woche kein Einfluss.
Auffälligkeiten
Im Mittel war alles glatt, aber ein paar „Momente“ gab’s natürlich trotzdem.
Der höchste Temperaturpunkt lag bei 77 °C am Samstag, 3. Mai 2026, 16:00 Uhr. Bei einem Wochen-Ø von 67,5 °C ist das ein klarer Ausschlag – aber thermisch komplett entspannt. 77 °C ist nicht „gefährlich“, das ist eher die Sorte Peak, wo ich kurz hängen bleibe und mir denke: welcher Mix war das gerade? Bei Dauer-100-%-CPU sind solche Peaks fast immer ein Hinweis auf anderen Instruktions-/Memory-Mix (oder einfach effizienter „dichtes“ Rechnen), nicht darauf, dass plötzlich „mehr als 100 %“ passiert.
Der Watt-Peak war 44 W am Mittwoch, 30. April 2026, 20:00 Uhr. Das sind rund 6,9 W über dem Durchschnitt von 37,1 W – merkbar, aber nicht wild. Genau die Art Spike, die ich bei Projektwechseln oder wechselnden WU-Charakteren erwarte: gleiche Auslastungszahl, aber andere elektrische Realität.
RAM-Peak bei 31,82 GB (50,84 %) ist ebenfalls eher „interessant“ als „knapp“. Mit 64 GB Gesamt-RAM und Swap 0 MB fühlt sich das stabil an. Eher so: Einstein zieht sich seinen großen Working-Set, und der Host nimmt’s gelassen.
Und wichtig: keine Temperatur-Drosselung / keine Events. Also keine versteckte Bremse, kein „wir retten uns gerade selbst“ – die Kiste hat die Peaks einfach weggesteckt und weitergerechnet.
Fazit
Das war eine Woche, die ich als souverän und effizient einsortiere: 99,5 % CPU, Load 8,34, dabei im Schnitt 37,1 W und 67,5 °C. Nicht spektakulär, aber genau diese langweilige Stabilität ist halt das, worauf man im 24/7-Crunching baut.
Einstein bleibt der Charakterkopf: lange Laufzeiten um ~40 Stunden und ~5,1 GB Working Set pro Task – das prägt RAM und (indirekt) auch das Temperatur/Watt-Gefühl. PrimeGrid ist der CPU-pure Marathonläufer, spacious bringt die schnelle Rotation rein, Asteroids bleibt angenehm schlank.
Und ja: 0 failed ist wieder mein Wochenhighlight. Draußen mild und klar, drinnen sauberer Crunch – kann von mir aus gerne so weiterlaufen. 🙂
Diagramme
Begriffe kurz erklärt
- BOINC: Ein Programm, das Rechenleistung vieler Computer bündelt, um wissenschaftliche Projekte gemeinsam zu berechnen.
- Einstein@Home: Ein Projekt auf BOINC, das nach Gravitationswellen und Pulsaren in Weltraumdaten sucht.
- PrimeGrid: Ein BOINC-Projekt, das nach besonders großen Primzahlen sucht.
- Asteroids@home: Ein Projekt, das Asteroidenbahnen berechnet, um deren Form und Bewegung besser zu verstehen.
- Working Set: Der Teil des Speichers, den ein Programm aktuell aktiv nutzt; zu klein bedeutet häufiges Nachladen.
- CPU-bound: Bezeichnet Programme, deren Geschwindigkeit hauptsächlich von der Rechenleistung der CPU abhängt.
- Memory-Controller: Ein Bauteil, das den Datenverkehr zwischen Prozessor und Arbeitsspeicher steuert.
- Scheduler: Der Teil des Betriebssystems, der entscheidet, welche Prozesse wann auf der CPU laufen dürfen.
- RPC failure: Ein Fehler, wenn ein Programm über das Netzwerk keine Antwort auf eine entfernte Anfrage erhält.
- llrSR5: Ein spezielles Rechenprogramm in PrimeGrid, das Primzahltests effizient auf mehreren Rechenkernen durchführt.
- Runqueue: Eine Warteschlange im Betriebssystem, in der Prozesse auf ihre Ausführung durch die CPU warten.
