Kaputte WU?

[Nemac]

An der 6056613 knuspert gerade eine Linuxkiste mit 8GB Ram. Rechner 19783
Damit haben wir eine Gegenprobe. Auch wenn mit der Gegenbeweis durch nen Windowsrechner lieber wäre..

ich bin gespannt

[Michael H.W. Weber]

Bitte poste den Ausgang hier.

Michael.

[Nemac]

Ist mir vorhin garnicht aufgefallen:
http://www.rnaworld.de/rnaworld/result. ... d=14861703
ist fertig mit der 6056613. Wir wissen nun aber immer noch nicht ob mehr RAM oder Linux hier die Lösung war

*grübel*

[Nemac]

Soo,
auch die WU 6054855 wurde gelöst, 8GB Ram, vermutlich Win.
Also vermute ich das yoyo recht hat. RAM Problem :|

Es scheinen aber immer mehr WUs mit dem Problem aufzutauchen :| (oder erst jetzt aufzufallen) Ich sehe ja nur meine Eigenen "Errors"

Workunit 6065176, 6066454, 6048353, 6057911. Wurden jeweils von Rechnern mit >8GB RAM gelöst.

Ein Fall für die Wissenschaftler, zusammenhänge erkennen

Edit: ist mir noch eingefallen: evlt ist garnicht das absolute RAM schuld, sonder die 2GB / Task grenze bei 32bit System? *grübel*

[Nemac]

Auch auf die Gefahr hin das es eh niemanden Interessiert.

Ich hatte gerade auf der VM (Computer 2082) die WU 6057911
http://www.rnaworld.de/rnaworld/workuni ... id=6057911

Und für die Wissenschaft ein wenig mitgeloggt. Die WU lief ab 20% alleine und war bis dahin Pausiert.

Die WU hat aber nie den gesamten RAM der VM, noch die 2GB, die für 32 bit Tasks zur Verfügung stehen sollten verbraucht.

*grübel*

Edit: die neuen WU die die VM bekommen sollte hatten laut Liste wieder Errors ;(
Ich zieh mich dann wohl erstmal zurück

[Michael H.W. Weber]

Also oben ist doch der Nachweis erbracht worden, dass die WUs problemlos berechnet werden können oder habe ich da jetzt etwas misinterpretiert? Ist da irgendwas mit Deiner VM nicht OK?

Michael.

[Nemac]

Gelöst wurden diese WUs bisher nur von Rechnern mit <4GB Ram, also vermutlich 64bit Kisten :|

[Michael H.W. Weber]

Welches OS im Einzelnen verwendet wurde (also auch ob 32 oder 64 Bit), steht in der Übersichtstabelle. Die fertigen WUs sind nun natürlich nebst Tabelle vom System schon entfernt worden, sodass man das wohl nicht mehr nachrecherchieren kann.

Was mir übrigens auch schwant ist, dass WUs, die die max. Zahl an "Fehlern" erreicht haben (wo wir ja wissen, dass zu dieser Zahl unsäglicher Weise auch die manuellen Abbrüche gezählt werden), ebenfalls einfach sang- und klanglos aus dem System entfernt werden. Oder führt BOINC darüber eine Statistik mit Detailinformationen, Yoyo?

Michael.

[yoyo]

Es gibt lediglich eine Datei, in der die WUs verzeichit sind, die nach max error abgebrochen wurden. Max error hatten wir im Übrigen vor einiger Zeit massiv erhöht.
yoyo

[Michael H.W. Weber]

Gut, somit ist zumindest gesichert, dass man keine WUs "aus den Augen verliert".

Michael.

[Ananas]

Die scheint eine Macke zu haben, der Wrapper restartet sie gelegentlich ohne den Abbruch zu bemerken.
Dadurch ist auch nicht festzustellen, wieso das cmsearch sich verabschiedet hat. Ich hatte zwischendurch mal die Ausgaben kontrolliert, daran war nichts auffaellig, die werden aber natuerlich nicht kumuliert sondern bei jedem Neustart ueberschrieben.

http://www.rnaworld.de/rnaworld/result. ... d=14870785

BOINC bekommt davon uebrigens ueberhaupt nichts mit, es ist ausschliesslich eine Sache zwischen Wrapper und cmsearch. Auffallen tut's nur, weil die CPU-Zeit wieder von 0 anfaengt (tatsaechlich lief sie ab Auslieferung aus BOINC-Sicht ununterbrochen).

Sowas hatte ich bisher noch nie :-/

p.s.: vielleicht liegt es ja am XML, da sind Zeilenvorschiebe drin, wo keine sein sollten, z.B.

Code: Alles auswählen

  <command_line>-o cms_GA-p[e30-50MB_Lin64f]_Gallus-gallus-(chicken)_CM000098.lin.EMBL_RF00177_SSU_rRNA_5_1330438623_52308_0 -T 0.0 --fil-T-hmm 0.0 --fil-T-qdb 0.0<EOL>
 RF00177_SSU_rRNA_5.cm Gallus-gallus-(chicken)_CM000098.lin.EMBL.fasta</command_line>

(hier mit EOL angemerkt)

und der Wrapper gibt das auch so an die Shell weiter :

Code: Alles auswählen

wrapper: running cmsearch (-o cms_GA-p[e30-50MB_Lin64f]_Gallus-gallus-(chicken)_CM000098.lin.EMBL_RF00177_SSU_rRNA_5_1330438623_52308_0 -T 0.0 --fil-T-hmm 0.0 --fil-T-qdb 0.0<EOL>
 RF00177_SSU_rRNA_5.cm Gallus-gallus-(chicken)_CM000098.lin.EMBL.fasta)

[yoyo]

Ich glaub nicht, dass es am EOL da drin liegt. Schließlich lief die erste Task der job.xml, der Forecast damit ordentlich durch und auch der Start von cmsearch sieht ordentlich aus. Im stderr wird das ordentlich protokolliert.

Für mich sieht das so aus, als ob der Wrapper 2 Mal von außen neu gestartet wird, denn er gibt 2 Mal
RNA World wrapper v0.04
aus. Das ist das erste was der Wrapper ausgibt, wenn er gestartet wird.

yoyo