Neues deutsches Bioinformatik-Projekt

boah, hab wieder so eine cmc_lin64 am wickel.
ist schon 86h am crunchen und steht erst bei 24% done :D
wehe die kackt wieder bei 99% ab, dann brech ich alle lin64 demnächst ab ;)
Falls es möglich ist und nicht zu sehr nervt ;D laß sie bitte durchrattern. Wir haben heute ein äußerst seltsames Problem bei einigen der ganz fiesen entdeckt und brauchen etwas mehr Daten, um der Sache auf die Schliche zu kommen. *suspect* Es scheint, daß einige direkt nach Fertigstellung (und ich vermute erfolgreicher Fertigstellung) einen Fehler erzeugen und dann als "client error" verbucht werden (obwbohl sie eigentlich intakt sind). Ich checke das durch und habe eine Vermutung, was da los sein könnte. Brauche aber mehr Daten.

Michael.

P.S.: Keine Sorge, Jungs - bin ebenfalls selbst mehrfach betroffen, denn mein 955 BE kaut auf den Lin-64ern rum, bis zum Abwinken. Ich sach nur: Ohren hoch und durch. ;D
 
Falls es möglich ist und nicht zu sehr nervt ;D laß sie bitte durchrattern. Wir haben heute ein äußerst seltsames Problem bei einigen der ganz fiesen entdeckt und brauchen etwas mehr Daten, um der Sache auf die Schliche zu kommen. *suspect* Es scheint, daß einige direkt nach Fertigstellung (und ich vermute erfolgreicher Fertigstellung) einen Fehler erzeugen und dann als "client error" verbucht werden (obwbohl sie eigentlich intakt sind). Ich checke das durch und habe eine Vermutung, was da los sein könnte. Brauche aber mehr Daten.

Michael.

P.S.: Keine Sorge, Jungs - bin ebenfalls selbst mehrfach betroffen, denn mein 955 BE kaut auf den Lin-64ern rum, bis zum Abwinken. Ich sach nur: Ohren hoch und durch. ;D

Ja vor ein paar tagen hatte ich das schon mal. bei 99.9%done plötzlich einen client error.
 
Ich hab vorhin nochmal 12 WUs bekommen, jetzt heißt es aber auch wieder:
"02/03/2010 01:57:48 RNA World Scheduler request completed: got 0 new tasks"
 
Ich hab vorhin nochmal 12 WUs bekommen, jetzt heißt es aber auch wieder:
"02/03/2010 01:57:48 RNA World Scheduler request completed: got 0 new tasks"
Ja, also dieses vorübergehende Problem haben wir ja nun ausführlich erklärt.

Was die CMC-Problematik betrifft sind wir einen Schritt weiter. Es scheint, als schreibt der Wrapper die müsam berechneten Ergebnisse nicht in die Ausgabedatei und liefert stattdessen die Inputdatei als Ergebnis ab. Das ist insofern logisch, als Inputdatei nach Abschuß der Berechnungen mit den neuen Inhalten als Outputdatei überschrieben wird. Bei diesem Schreibprozeß hapert es. Dieselben WUs laufen lokal fehlerfrei durch. Daher habe ich den Wrapper im Visier. Sollte von euch jemand eine Idee haben, was da quer läuft wäre ich für Hinweise sehr dankbar.

Michael
 
Ich könnte mir vorstellen dass die Datei aus welchen Gründen auch immer (noch) (durch das OS) gelockt ist und daher nicht überschrieben werden kann.

Könnt ihr denn keine neue Ausgabedatei erzeugen und nachdem diese erfolgreich erstellt wurde die Input-Datei löschen?
 
Vielleicht hält noch ein Prozess einen Lock auf der Inputdatei?
Warum erstellt ihr keine neue Outputdatei, wie z.B. 'Inputdateiname_out' oder ähnlich?
.
EDIT :
.

Haha, zwei dumme ein Gedanke 8)
 
Vielleicht ist das ein ähnliches problem wie es QMC@Home vor ein paar Monaten hatte. Dort waren ebenfalls sehr große WUs im Umlauf die regelmäßig gegen Ende abbrachen. Der Grund bei denen war ,das das Ausgabefile zu groß wurde. Wenn man darauf in der client_state.xml den Wert der maximalen Größe der Ausgabedatei für jede WU hochgesetzt hatte ging es jedoch.
 
Jungs, das sind zwei Ideen, die wir umgehend beleuchten werden, wobei die Größe der Ausgabedatei kaum das Problem sein kann, aber der Prozeß des Dateilockings, der interessiert mich. Was man damit allerings nicht erklären kann ist, warum kleinere CMCs nicht dasselbe Problem haben. Aber wir werden sehen... ;)

Michael.
 
so. jetzt iat es wieder passiert.
nach 195.000sek berechnungszeit wieder abgebrochen.
und diese WU ist schon 11x mit compute error abgebrochen. ist nun aber beim nächsten tropf am crunchen ;)
http://www.rnaworld.de/rnaworld/workunit.php?wuid=158911
komisch ist die crunch-zeit. im BM wurde schon über 90h abgezeigt, aber die WU meldet "nur" rund 56h.

edit: kommando zurück. das war die "alte" WU die bei mir abbrach. die aktuelle steht bei 113h und rund 29% done!! Ich schätze also mal dass die rund 350h brauchen wird!!
wehe das gibt nicht ordentlich credits ;)
 
Zuletzt bearbeitet:
so. jetzt iat es wieder passiert.
nach 195.000sek berechnungszeit wieder abgebrochen.
und diese WU ist schon 11x mit compute error abgebrochen. ist nun aber beim nächsten tropf am crunchen ;)
http://www.rnaworld.de/rnaworld/workunit.php?wuid=158911
komisch ist die crunch-zeit. im BM wurde schon über 90h abgezeigt, aber die WU meldet "nur" rund 56h.

edit: kommando zurück. das war die "alte" WU die bei mir abbrach. die aktuelle steht bei 113h und rund 29% done!! Ich schätze also mal dass die rund 350h brauchen wird!!
wehe das gibt nicht ordentlich credits ;)
Ich drück Dir die Daumen
 
Vielleicht ist das ein ähnliches problem wie es QMC@Home vor ein paar Monaten hatte. Dort waren ebenfalls sehr große WUs im Umlauf die regelmäßig gegen Ende abbrachen. Der Grund bei denen war ,das das Ausgabefile zu groß wurde. Wenn man darauf in der client_state.xml den Wert der maximalen Größe der Ausgabedatei für jede WU hochgesetzt hatte ging es jedoch.
Das ist IMO nicht das Problem.
- Dann wäre es ein andere Boinc Fehlercode, sowas wie MAX_OUTPUT_SIZE reached.
- Der Output ist lediglich ~200k uncomprimiert, wird aber komprimiert und die max Größe ist auf 1MB gesetzt.

Vielleicht hält noch ein Prozess einen Lock auf der Inputdatei?
Warum erstellt ihr keine neue Outputdatei, wie z.B. 'Inputdateiname_out' oder ähnlich?
Ein lock ist da auch nicht drauf, dann würden die anderen wus ja auch alle nicht funktionieren.
yoyo
 
Tritt der Fehler nur unter Linux auf? Vielleicht ein Fehler mit dem Shellaufruf und/oder den Rechten auf die Datei? (sieht ja so aus als wenn der Checkpoint nicht geschrieben wird).
 
die aktuelle steht bei 113h und rund 29% done!! Ich schätze also mal dass die rund 350h brauchen wird!!
wehe das gibt nicht ordentlich credits ;)
...die ist doch klein. ;D Duck und wech...

Probiert bitte im Falle des Falles Yoyos Vorschlag:

Please run on your Linux box the following command if your wu has reached more than 95%:

Code:
strace -p <pid of cmcalibrate> | tail -1000000000 > strace.out

This will create a trace file with a maximum size of 1GByte. This might be useful to find the error.
Michael.
 
Jetzt zählt das blöde ding rückwarts. die WU war ja schon bei knapp 30% done, heute morgen war sie dann bei 16%?
 
Jetzt zählt das blöde ding rückwarts. die WU war ja schon bei knapp 30% done, heute morgen war sie dann bei 16%?
Machst Du mit dieser WU bitte mal den oben beschrieben Test und zusätzlich folgendes:

Code:
ulimit -a
Dann die Ausgabe dazu hier posten. Danke! ;D

Michael.

P.S.: Bis auf 4 WUs haben wir das CMC Arbeitspaket nun durchgekaut. Wir haben unsere HR Einstellungen weiter verbessern können und somit den Durchsatz des Projekts erhöht.
 
Zuletzt bearbeitet:
dauert aber noch, die kiste steht zuhause und ich bin heute bis 24.00 auf arbeit. wird also erst morgen abend was ;)

p.s. was für eine Ausgabe? Um es mal klar zu sagen, die linux kiste läuft für boinc und surfen, bin keine "echter" linux´er ;)
 
dauert aber noch, die kiste steht zuhause und ich bin heute bis 24.00 auf arbeit. wird also erst morgen abend was ;)

p.s. was für eine Ausgabe? Um es mal klar zu sagen, die linux kiste läuft für boinc und surfen, bin keine "echter" linux´er ;)
Terminal öffnen (unter Zubehör) und dann die Order geben. ;D Da wird die Kiste dann was auswerfen und das kannste per Copy & Paste hier reinkleistern.

Michael.
 
Zuletzt bearbeitet:
Hier scho mal was bei ulimit -a rauskam
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 20
file size (blocks, -f) unlimited
pending signals (-i) 16382
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) unlimited
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
das trace-file lass ich aber erst anlegen wenn die WU bei 95% steht, richtig?
 
So, die angekündigten neuen CMCs für Windows x64 sind eingestellt und werden gerade vom Server prozessiert. Ab Morgen gibt es für alle Maschinen ein erstes CMS Testpaket (genau 2048 x 3 WUs) der Eukaryonten - inklusive des kompletten menschlichen Genoms. Aber Vorsicht: Diese CMS werden teils deutlich länger laufen, als was ihr bisher kennt - mit bis zu 100 Std. pro WU. Desweiteren sind die Transfervolumina ein bis zwei Größenordnungen höher, also ohne Breitband werdet ihr ggf. Probleme bekommen. Deshalb auch erst einmal ein einziges Testpaket. ;D

Michael.
 
Vor wenigen Minuten hat unser Server damit begonnen für alle Systeme die ersten Eukaryontengenome zu prozessieren, sodaß in Kürze die Auslieferung starten sollte. ;D

Michael.
 
Mal ein paar gezogen, ich glaub so um die 20-30.
Korrigiere, 40.
 
Zuletzt bearbeitet:
Achtet etwas auf eure Maschinen. Wir haben einige CMS WUs dabei, die wirklich Arbeitsspeicher fressen. Leider gibt es (noch) keine Möglichkeit der RAM-Bedarfsabschätzung, sondern bislang nur die Laufzeitvorhersage. Insofern bleibt uns nichts übrig, als es auszuprobieren. Ich bitte deshalb um Verständnis und habe die FAQ heute bezügl. CMSEARCH RAM-Bedarf um die neuen Erkenntnisse erweitert. :)

Michael.
 
Achtet etwas auf eure Maschinen. Wir haben einige CMS WUs dabei, die wirklich Arbeitsspeicher fressen. Leider gibt es (noch) keine Möglichkeit der RAM-Bedarfsabschätzung, sondern bislang nur die Laufzeitvorhersage. Insofern bleibt uns nichts übrig, als es auszuprobieren. Ich bitte deshalb um Verständnis und habe die FAQ heute bezügl. CMSEARCH RAM-Bedarf um die neuen Erkenntnisse erweitert. :)

Michael.
Jo, eine hat sich bis auf

2,3 GiB​

aufgebläht. Meine 12 Gib haben nicht ausgereicht!:o:o:o:o:o:o:o:o

Dazu kommt noch das Aufgaben die 4 Stunden dauern kein Checkpointing haben. Da wird das crunchen zum Glücksspiel!
 
Zuletzt bearbeitet:
Bis lang alles gut, Ram Nutzung hält sich zurück. Dafür hüpft die Auslastung munter im 1/100 sec Takt. *lol*
 
Zurück
Oben Unten