Ich hab mich eingeloggt, während es hier in Passau so richtig „grau & gedämpft“ war – 21,0 °C, komplett bedeckt, alles irgendwie auf Leise. Und dann schaust du auf die Telemetrie und denkst dir: okay, draußen ist Pause, aber donau2space macht exakt das Gegenteil. Der rechnet stoisch weiter, als wär’s ihm egal, ob’s Mittwoch ist oder Samstag.
Schneller Überblick
Zusammenfassung
Im Zeitraum vom 24. bis 27. Juni 2026 lief der donau2space-Server unter hoher Auslastung (99,6 % CPU, 39,0 W, 70,7 °C Durchschnittstemperatur) stabil ohne spürbare Engpässe. Besonders Einstein@Home forderte die Ressourcen, während andere Projekte wie Asteroids@home und PrimeGrid unterschiedlich CPU- oder RAM-lastig waren. Die Uptime lag bei über 3.483 Stunden.
Auf den Punkt
- Server läuft stabil mit minimalem Swap-Einsatz.
- Einstein@Home ist das ressourcenintensivste Projekt.
- PrimeGrid-Aufgaben variieren stark in Laufzeit und RAM-Bedarf.
- RAM-Zusage im Schnitt 24,4 GB, Peak bei 36,52 GB (64 GB gesamt).
- 22 fehlgeschlagene BOINC-Jobs, aber keine Netzwerkprobleme.
- Maximale CPU-Temperatur: 77 °C, maximaler Verbrauch: 45 W.
- 5 aktive Projekte, davon 4 mit laufender Aktivität.
FAQ
- Wie hoch war die durchschnittliche CPU-Temperatur?
- 70,7 °C.
- Gab es während des Zeitraums Systeminstabilitäten?
- Nein, es wurden keine Drosselungen oder kritische Fehler festgestellt.
- Welches Projekt beanspruchte den meisten Speicher?
- Einstein@Home.
Serverstatus & Telemetrie
Der Zeitraum ist von Mittwoch, 24. Juni 2026, 7:00 Uhr bis Samstag, 27. Juni 2026, 18:00 Uhr. Die Uptime steht beim letzten Wert bei 3.483,28 Std. – das ist für mich so ein stilles Qualitätsmerkmal. Nicht „wow“, sondern eher: keine Zicken, kein Rumgezicke im Stack, einfach Betrieb.
Im Schnitt lief die CPU bei 39,0 W und 70,7 °C, bei 99,6 % Usage. Das ist ein ziemlich „ehrlicher“ Dauerlast-Zustand für den i7-7700: voll ausgelastet, aber nicht gequält. 70,7 °C im Mittel fühlt sich für 24/7-Crunching stabil an – nicht kalt, aber auch weit weg von diesem Bauchgefühl, wo man sofort die Lüfterkurve hinterfragt.
Der Load1 bei 8,35 auf 8 Threads ist genau dieses „sitzt perfekt auf Anschlag“-Gefühl in htop: die Kerne sind komplett beschäftigt, aber wir bauen keinen absurden Rückstau auf. Minimal drüber ist okay – das heißt für mich: der Scheduler hat immer Arbeit, ohne dass das System anfängt „zäh“ zu wirken.
Beim RAM sieht’s entspannt aus – zumindest im Durchschnitt: 24,4 GB (39,0 %). Das ist deutlich weniger „Speicherdruck“ als letzte Woche im Kontextartikel, und es passt dazu, dass nicht dauerhaft mehrere Einstein-Klopper gleichzeitig das RAM vollschaufeln. Und das Wichtigste: Swap 4 MB. Das ist praktisch nix. Sobald Swap wirklich ins Spiel kommt, fühlt sich ein Cruncher nicht mehr souverän an – hier wirkt das System aber klar nicht unter Speichernot.
Storage ist langweilig gesund: 201,1 GB total, 167,8 GB frei. BOINC belegt 9.183,86 MB – und ja, das riecht wieder hart nach Einstein@Home, weil die einfach ihren Daten-Fußabdruck mitbringen. Aber es ist stabil und nicht „schleichend kritisch“.
BOINC gesamt: 6.538 Jobs succeeded, 22 failed. Das ist der Punkt, wo ich automatisch genauer hinschaue. 22 ist nicht „Weltuntergang“ bei dem Durchsatz, aber es ist auch nicht die Null, die mich innerlich am meisten freut. Positiv und wichtig: 0 RPC failures und 0 fetch failures – also kein Netzwerk-/Scheduler-Gezicke. Wenn was schiefgeht, dann wirkt’s eher projekt-/WU-spezifisch als „meine Kiste kann nicht sauber reden“.
Projekte im Detail
Hier laufen 5 Projekte, wobei climateprediction.net faktisch weiter auf 0 steht (0 Credit, 0 Jobs) – also im Moment eher „registriert“ als aktiv.
Einstein@Home – der schwere Block (CPU + RAM)
Einstein dominiert die Statistik brutal: 4.194.720 Credit bei einem expavg von 29.245,46. Das ist kein Projekt, das „kurz mal“ läuft – das ist eher der Dauerbrocken, der den Rechner in so einen gleichmäßigen Langstreckenmodus zwingt.
Und man sieht auch warum: in den aktiven Tasks tauchen Working-Sets von 4.349 MB, 4.739 MB, 4.816 MB auf – und dann dieser eine Task mit 8.305 MB. Das ist genau die Sorte Last, die nicht nur die ALUs beschäftigt, sondern die Speicherhierarchie mit. Mehr RAM-Footprint heißt: mehr Datenbewegung, mehr Memory-Controller-Aktivität – und damit oft auch ein bisschen mehr Wärme/Watt, obwohl „nur CPU“ gerechnet wird.
Was ich dabei spannend finde: Trotz dieser fetten Einstein-WUs bleibt der RAM im Wochenschnitt relativ niedrig (24,4 GB). Das deutet für mich darauf hin, dass entweder nicht ständig mehrere 8-GB-WUs gleichzeitig laufen oder dass der Mix gerade so ist, dass Einstein zwar präsent ist, aber nicht in der „RAM drückt alles an die Wand“-Phase.
Von der Laufzeit her ist Einstein ganz klar der Langläufer: zuletzt erledigt war ein Einstein-Task mit 37h 0m. Scheduler-technisch heißt das: wenig Rotation, wenig Overhead, lange konstante Last. Das ist für die CPU thermisch oft angenehmer als dauernd kurze Jobs, die ständig neue Phasen/Instruktionsmixe reinwerfen.
spacious@home – Rotation, sauberer Takt, wenig Drama
spacious@home ist bei 178.846,263753 Credit und expavg 1.255,82. Bei den zuletzt erledigten Tasks waren es 10 Tasks mit Ø 49m 54s. Das ist genau dieses „Metronom“-Projekt: es reportet oft, es bewegt sich ständig was, aber es fühlt sich nicht chaotisch an.
RAM-seitig sieht man bei den aktiven Tasks Spannweite: von 4 MB bis 223 MB Working Set. 223 MB sind auf 64 GB natürlich völlig harmlos – aber diese Varianz ist interessant, weil genau sowas kleine Watt-/Temp-Unterschiede erklären kann: nicht weil es „viel“ wäre, sondern weil es auf unterschiedliche Datensätze und Zugriffsmuster hindeutet.
Asteroids@home – eher leicht, viel Bewegung
Asteroids@home steht bei 125.059,230098 Credit und expavg 813,64. Zuletzt liefen 7 Tasks mit Ø 1h 8m. Also: länger als spacious, aber immer noch klar „Rotation“.
In den aktiven Einträgen fällt auf, dass da einige UNINITIALIZED/READYTOREPORT hängen. Solange die Fehlerrate nicht explodiert und das Reporting nicht festklemmt, ist das für mich eher ein Zwischenzustand als ein Problem – aber es ist genau so ein Detail, das ich beobachte, weil’s sonst gerne mal in Richtung „warum stapelt sich das?“ kippt.
PrimeGrid – CPU-bound, aber gerade mit zwei Gesichtern
PrimeGrid steht bei 801.693,940033 Credit und expavg 6.623,87. Bei den zuletzt erledigten Tasks waren’s 2 Stück mit Ø 2m 6s – also super kurz.
Gleichzeitig läuft aktiv ein PrimeGrid-Task, der schon 21h 29m CPU-Time hat und ein Working Set von 178 MB zeigt. Das ist genau der PrimeGrid-Charakter, den ich mag: meistens sehr CPU-bound, RAM praktisch nebensächlich, aber je nach Subprojekt kann’s entweder ultrakurz oder richtig lang werden. Und dieser Mix kann auch erklären, warum Watt/Temp nicht komplett „glatt“ sind.
Auffälligkeiten
Keine Temperatur-Events, keine Drosselung – das System wirkt die Woche eher wie „läuft einfach“. Aber die Peaks sind trotzdem so kleine Momente, wo ich kurz innerlich stehenbleib.
Die maximale Temperatur lag bei 77 °C am Donnerstag, 26. Juni 2026, 22:00 Uhr. Bei 70,7 °C im Schnitt ist das kein Alarm, eher ein kurzer Ausreißer nach oben. Ich seh 77 °C und denke nicht „oh nein“, sondern eher: okay, welcher Workunit-Mix war das gerade? Oft ist das genau so ein Zeitpunkt, wo mehrere speicherlastigere Einstein-WUs parallel laufen oder wo durch Rotation (spacious/asteroids) mehr „Unruhe“ in den Instruction-Mix kommt.
Der maximale Verbrauch war 45 W am Freitag, 27. Juni 2026, 0:00 Uhr. Das ist ebenfalls absolut im Rahmen – aber es zeigt, dass der i7-7700 gelegentlich etwas „schwerere“ Phasen sieht. Watt-Spikes passen häufig zu Workunit-Typen, die entweder mehr Vektorlast fahren oder mehr Speicherzugriffe produzieren. Interessant ist: Temp-Peak und Watt-Peak liegen nicht identisch – das spricht eher für unterschiedliche Ursachen (einmal thermisch träge + Umgebung/Lastverlauf, einmal elektrisch/Instruktionsmix).
RAM hatte einen Peak bei 36,52 GB (58,35 %). Das ist für 64 GB komfortabel. Es ist so ein Wert, wo ich denke: ja, Einstein war da, aber eben nicht „wir sind am Anschlag“. Und weil Swap praktisch nicht genutzt wird, fühlt sich das eher nach „satt“ als nach „gestresst“ an.
Fazit
Das war eine ziemlich saubere, stabile Cruncher-Phase: 99,6 % CPU, 39,0 W und 70,7 °C im Mittel, keine Drossel-Events. Genau die Art Woche, wo man merkt: Stabilität ist nicht langweilig – sie ist ein Zustand, den man sich erarbeitet.
Der einzige Wert, der bei mir ein kleines Fragezeichen setzt, sind die 22 failed Jobs. Nicht panisch, eher neugierig: das ist genug, um’s nicht zu ignorieren. Gleichzeitig beruhigt mich extrem, dass RPC/fetch komplett bei 0 bleiben – das System selbst wirkt nicht wacklig, eher einzelne Workunits/Projektbedingungen.
Und ja: ein Teil von mir findet’s fast ein bisschen schade, dass die Kurven nicht „wilder“ sind… aber dann sehe ich die 3.483,28 Std. Uptime und denk mir: genau so soll ein Cruncher eigentlich aussehen.
Diagramme
Begriffe kurz erklärt
- Einstein@Home: Ein verteiltes Rechenprojekt, bei dem viele Computer gemeinsam nach Anzeichen für Gravitationswellen oder Pulsare suchen.
- Asteroids@home: Ein Projekt, das mithilfe vieler Computerformen von Asteroiden berechnet, um ihre Bahn und Gestalt besser zu verstehen.
- PrimeGrid: Ein freiwilliges Rechenprojekt, das nach besonders großen Primzahlen sucht und dabei viele Computer weltweit vernetzt.
- Uptime: Zeigt an, wie lange ein Computer oder System bereits ohne Unterbrechung läuft.
- Load1: Gibt an, wie stark das System in der letzten Minute mit Aufgaben ausgelastet war.
- Scheduler: Der Teil des Betriebssystems, der entscheidet, welche Programme wann Prozessorzeit bekommen.
- Workunit: Ein kleiner Rechenauftrag, den verteilte Projekte an einzelne Computer schicken.
- Working Set: Die Menge an Daten und Programmcodes, die ein Prozess gerade aktiv im Speicher nutzt.
- CPU-Time: Die Zeit, die der Prozessor tatsächlich mit Rechnen für eine Aufgabe verbringt.
- RPC failures: Fehler beim Datenaustausch zwischen Computern über das Netzwerk, wenn ein Remote-Aufruf nicht klappt.
- Memory-Controller-Aktivität: Misst, wie stark der Speichercontroller beschäftigt ist, Daten zwischen RAM und Prozessor zu bewegen.
