Skip to content

in die Knie

Wer (wie ich) in diesen Tagen mal das Problem hat, dass sein BOINC für mehrere Minuten nicht reagiert, nachdem es neu gestartet wurde, sollte mal einen Blick in die diversen slots-Verzeichnisse werfen. Eventuell liegt da ein Verzeichnis 'minirosetta_database' rum. Beim Starten versucht der BOINC-Client das Verzeichnis und alle darin enthaltenen Dateien zu entsorgen, was wegen Read-Only-Attribut nicht funktioniert. Dummerweise meint der Client, für jede einzelne Datei erstmal 5 Sekunden warten zu müssen, bevor er einen weiteren (natürlich erfolglosen) Löschversuch unternimmt. Dadurch sind in meinem Fall 20 Minuten draufgegangen, in denen der BOINC Manager sich mit dem CoreClient nicht verbinden kann, und der CoreClient auch keine Tasks startet.

Verursacher des überflüssigen Verzeichnisses ist offensichtlich das Rosetta-Alpha-Projekt 'ralph@home'. Eine mögliche Lösung gibt es zwar auch schon, aber die ist heute erst eingecheckt worden, was bedeutet, dass sie weder in den BOINC-Versionen bis einschließlich 5.10.35, noch in der zur Zeit nicht offiziell freigegebenen Version 6.1.6 enthalten sein kann.

Eine manuelle Lösung besteht darin, erstmal zu schauen, ob auch nirgendwo ein rosetta Mini laufen sollte, den Client zu stoppen, und das störende Verzeichnis selbst zu löschen (oder zu verschieben). Danach startet BOINC dann auch wieder in der gewohnten Geschwindigkeit.

zerputtet

Wie es aussieht, habe ich es eben geschafft, meine Reiser-Partition meines bisherigen Hauptrechners zu zerschießen, indem ich die Platte in den neuen Server-Rechner eingebaut habe. Dummerweise hat das Knoppix auf dem Rechner weder die eingebaute, noch meine bisherige Festplatte erkannt, so dass ich auf dem Rechner auch keine weitergehenden Versuche unternehmen konnte. Wie es aussieht, wird diese Nacht dann wohl doch länger :-(

Aufgabe erfüllt

Eben gerade hat mein Notebook die letzte WU aus der übereifrigen Sammelei zurückgemeldet. Das heißt, die WUs, die sich das System 'angefressen' hatte, haben für 1,5 Monate gereicht. Wahrscheinlich hätte die letzte WU schon vorher erledigt sein können, wenn der CoreClient sich nicht inzwischen von verschiedensten Projekten neue Arbeit geholt hätte. Die WU, die eben erledigt wurde, hätte sich spätestens am 17. gegen 1:00 Uhr melden müssen. Zum Schluss wurde die WU deswegen auch nicht im Deadline-Modus mehr behandelt, die Deadline war ja gesichert. Das beweist dann recht eindrucksvoll, dass der neue CPU-Scheduler brav das tut, was er tun soll. Der neue Workfetch-Code läuft hier zwar erst seit heute früh, aber bisher kann ich mich auch über den nicht beschweren.

Ärgerlicher Absturz

Daran, dass der jeweils neueste (Alpha-) BOINC-Client beim Reaktivieren der Netzwwerkverbindung ganz gerne mal abstürzt, habe ich mich ja schon gewöhnt. Dann warte ich eben, bis die Wissenschaftlichen Anwendungen nach 30 Sekunden ohne heartbeat vom Client sich beenden, und starte den BOINC-Manager neu. Heute früh hat das aber nicht gereicht. Anscheinend hat der CoreClient die client_state.xml in einem inkonsistenten Zustand hinterlassen, beim Neustart waren jedenfalls alle Tasks weg. Zu meiner großen Freude habe ich aber eine Kopie der client_state.xml von vor einer Woche wiedergefunden, die ich dann testhalber mal eingesetzt habe (Ich lege ja keinen gesteigerten Wert darauf, die bisher erbrachte CPU-Zeit für CPDN zu opfern oder die noch offenen QMC-Tasks von Anfang Juli. Der Versuch hat auch insofern funktioniert, als eben diese Tasks dem CoreClient wieder bekannt waren. Zusätzlich waren allerdings auch ein paar Tasks enthalten, die inzwischen schon erfolgreich berechnet, hochgeladen und zurückgemeldet worden waren. Diverse Tasks haben recht schnell ihre Eingabedateien vermisst und sind mit Berechnungsfehlern abgebrochen. Zur Sicherheit, dass ich nicht QMC-Tasks doppelt berechne, habe ich auch noch zwei Tasks manuell abgebrochen, aber ob das reicht, weiß ich erst, wenn die erste Task demnächst zurückgemeldet wird. Sicherheitshalber habe ich eben noch eine Kopie der client_state gemacht, man weiß ja nie, ob das Problem nicht demnächst wieder zurückkommt.

Übereifrig

Da ist man mal kurz nicht da, und schon dreht der BOINC-Client durch.

Ich habe jetzt die lauschige Anzahl von 264 Tasks auf dem Notebook.

Das setzt sich dann so zusammen:

52 x Rosette (drei Stunden Laufzeit, fällig am 8.7.)
51 x Simap (1,5 Stunden jeweils, fällig am 11.7.)
73 x Leiden (Laufzeiten von unter 10 Minuten bis 30 Minuten, fällig am 7.7.)
1 x ClimatePrediction (Rest-Laufzeit von < 2500 Stunden, fällig zu Weihnachten 2007)
9 x Einstein@home (Laufzeiten von knapp 24 Stunden, fällig am 15.7.)
14 x QMC@HOME (Laufzeit von 37 Stunden, fällig am 17.8.)
2 x RALPH (Laufzeit eine knappe Stunde, fällig am 4.7.)
21 x SETI (Laufzeiten zwischen 5 und 10 Stunden, fällig zwischen dem 14. und dem 26.7.)
31 x Seti-Beta (Laufzeiten knapp über 3 Stunden, fällig am 24.7.)
5 x uFluids (Laufzeit je knapp 30 Stunden, fällig am 15.7., die Teile schreiben immernoch keine Checkpoints)
5 x XtremLab (Laufzeit von 10 Minuten, fällig am 6.7.)

Daran hat der neue Scheduler jetzt jedenfalls erstmal zu knabbern. Erstmal versucht er sich an den Leiden-WUs, von denen er gleich vier weggecruncht hat.

24:51:21

Das ist die (CPU-)Zeit, die mein Windows-Notebook gerade an einer uFluids-Aufgabe rumgerechnet hat. Dank dem neuen scheduler, der in der neuesten Test-Version des BOINC-Client enthalten ist, hat der Rechner die Berechnung nicht unterbrochen (uFluids scheint den Trick mit den Checkpoints noch nicht hinbekommen zu haben). Unpraktischerweise enthielt die BOINC-Version, die ich verwendet habe, noch einen Fehler im Scheduler, so dass seit gestern irgendwann nur noch einer der beiden CPU-Kerne benutzt wurde. So musste ich bis eben abwarten, bis die Task abgeschlossen war, um die neueste Beta-Version installieren zu können. Wenn ich jetzt noch rausfinden würde, wie ich der Version beibringe, dass sie mir ruhig ausführlicher erzählen darf, was der Seduler so beschließt, dann wäre ich zufrieden. Aber vielleicht dauert ws ja auch nicht mehr so lange, bis die nächste Version rauskommt, die dann ja wohl ein komplett umgebautes Logging enthalten soll.

Klima-Vorhersage und das tödliche Rinnsal

Wie man heute auf der News-Seite des Climateprediction.net-Projektes nachlesen kann, hat sich in viele Modelle ein Fehler eingeschlichen, der die Berechnungen für den angestrebten Zweck unbrauchbar macht. Details sind in einem Forenbeitrag festgehalten. Deswegen versendet das Projekt jetzt 'Killer-Trickles', die die laufenden Modelle beenden. scheinbar ist aber der Ansturm auf die Server im Moment so groß, dass die Datenbank zusammengebrochen ist. Hoffen wir mal, dass das tödliche Rinnsal nicht noch die Datenbank erwischt.

Mitmach-BOINC

Es ist mal wieder Zeit für eine Frage aus dem Mitmach-Blog, und ich dachte mir, dass ich mal nachfragen kann, wer von Euch eigentlich auch BOINCt, und bei welchen Projekten.

Ich habe mich zu meiner Motivation ja schon vor geraumer Zeit mal geäußert.

Operation geglückt

Ich habe eben mal bei einem meiner Linux-Rechner die aktuellste Version des Programms von Climateprediction transplantiert. War an sich recht einfach. Ich habe mich einfach an der Beschreibung orientiert, die in den Foren veröffentlicht ist, wobei ich die Inhalte der XML-Datei natürlich von einem bereits laufenden Client übernommen habe. So wie es aussieht, hat die Operation nicht nur geklappt, sondern auch den versprochenen Geschwindigkeitszuwachs erbracht. Ob das Programm jetzt beim Pausieren nicht mehr crasht, will ich allerdings garnicht ausprobieren.

Endlich stabil

Es hat ein paar Tage gedauert, aber jetzt scheint der BOINC-Client von SIMAP(über das ich ja bereits mal kurz berichtet habe) auch unter Linux relativ stabil zu sein. Version 5.05 stürzt jetzt nicht mehr direkt beim Starten mit einem SegFault ab. Schön wäre jetzt noch, wenn der sulphor-Client für Linux von climateprediction.net sich abgewöhnen würde, SegFaults beim suspend zu erzeugen. Die Option 'Leave apps in memory' habe ich zwar eingeschaltet, aber auf meinem alten Rechner stürzt das Programm trotzdem gerne ab, am Liebsten beim Booten.

Leider habe ich bisher keine Reaktion eines Entwicklers oder Admin zu diesem Problem erhalten.

Noch lebt's

Heute ist ja der Tag, an dem SETI Classic abgeschaltet werden soll. Bisher scheint das Projekt aber noch erreichbar zu sein.

Warum ich bei BOINC mitmache

Ich habe schon oft die Frage gestellt bekommen, warum ich eigentlich meine Rechenzeit für BOINC zur Verfügung stelle. Das hat mehrere Gründe:

  • Wissenschaft: Jedes der Projekte, an denen ich mitrechne dient einem wissenschaftlichen Zweck. Man kann also davon ausgehen, dass durch diese Projekte in irgendeiner Form neue Erkenntnisse gewonnen werden.
  • Das Gefühl, dabei zu sein: Ich gebe es offen zu, irgendwo erhoffe ich mir, von dem Ruhm, den ein solches Projekt einfahren könnte, auch etwas abzubekommen, oder wenigstens später sagen zu können "ich war dabei".
  • Wettbewerb: Dazu kommt noch ein Wettbewerb zwischen den Leuten, den Teams, den Nationen. Ich weiß, dass ich mit meinen Rechnern nicht der Schnellste bin, aber das hindert mich ja nicht daran, möglichst viel zu schaffen.
"Warum ich bei BOINC mitmache" vollständig lesen
tweetbackcheck