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 :-(

ComPod #28: Früh-Sommer

Im heutigen, frühsommerlichen Podcast werfe ich einen Blick auf das, was in der letzten Woche interessant war, erzähle was BOINC ist und was ich mit einem 8-Kern-Rechner machen würde.

Musikalisch gibt es dieses Mal Jesse Malin mit dem Titel 'Broken Radio', Laura Smith mit dem Titel 'Every Breath', Stimmkraft mit dem Titel 'Frei für immer'

Länge: 55:18, 52 MB.

Über Kommentare hier oder bei Podster würde ich mich natürlich auch wieder freuen. Bei iTunes könnt ihr den ComPod inzwischen auch ganz einfach abonnieren. In den Podcastcharts bei Trackback dürft Ihr jetzt auch wieder für mich stimmen. ;-)

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.

Alles neu macht der Juli

Ich war eben ganz spontan mal wieder in 'meinem' Waschcenter. Da wurde ja in den letzten Wochen/Monaten die Technik umgebaut, wie ein sehr lesenswerter Aushang erklärte. Der Umbau scheint soweit erledigt zu sein. Die neuen, metallverkleideten Waschmaschinen sehen etwas moderner aus, als die alten Maschinen. Auch deren Bedienung hat sich etwas geändert, aber auch darin kann man sich eindenken. Bei den Preisen hat sich nicht viel getan, wenn man davon absieht, dass das Waschmittel jetzt immer separat gekauft werden muss, wodurch der Anreiz, eigenes Waschmittel mitzubringen einfach größer wird.

Weniger gut war, dass ich miterleben durfte, wie eine der tollen, neuen Maschinen nicht funktionierte. Ein anderer Kunde hatte seine Wäsche in eine Maschine gesteckt und sich auch ganz normal die Maschine und das Waschpultver besorgt. Als er die Maschine gestartet hat, war die allerdings anscheinend der Überzeugung, die wasserlose Wäsche vollziehen zu müssen. Immerhin weiß ich jetzt, wie man die Waschmaschinen vorzeitig abschaltet.

Bei den Wäschetrocknern gab es auf den ersten Blick keine großen Änderungen, die Geräte sind immernoch die selben Geräte wie vor dem Umbau. Auf den zweiten Blick gab es aber doch eine Änderung, so dass man am Auswahlpanel immer nur eine 10-minütige Trockeneinheit bezahlen kann. Das führt dann dazu, dass man nach 10 Minutennochmal 50 Cent einwerfen darf, um die (mindestens benötigten) 20 Minuten zu erreichen. Dass zwischendurch die Heizung in dem Trockner abgeschaltet wird, weil ja nach 10 Minuten die bezahlte Trocknungsdauer endet, muss ich wohl nicht extra erwähnen.

Wenn man mit diesen Verbesserungen Veränderungen umgehen kann, hat man aber hinterher wieder saubere, trockene Wäsche. Trotzdem gewinnt die Idee einer eigenen Waschmaschine mit Trockner einen gewissen Reiz auszuüben.

Ü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.