offener Betatest für neue cmsearch VM Anwendung

[Uwe Sänger Herzke]

Bei mir waren eben 2 Wutzen in der VBox am werkeln, obwohl im BM beide auf "Berechnungsfehler" standen, 1x RNA-World und 1x T4T.
Hier wäre die RNA: cmsvm_GA-p[e20-30MB_Lin64f]_1_Drosophila-simulans_CM000363.lin.EMBL_RF00028_Intron_gpI_1349111823_23352_8
Und der stderrr ganz unten:

Code: Alles auswählen

</stderr_txt>
<message>
upload failure: <file_xfer_error>
  <file_name>cmsvm_GA-p[e20-30MB_Lin64f]_1_Drosophila-simulans_CM000363.lin.EMBL_RF00028_Intron_gpI_1349111823_23352_8_0</file_name>
  <error_code>-161</error_code>
</file_xfer_error>
<file_xfer_error>
  <file_name>cmsvm_GA-p[e20-30MB_Lin64f]_1_Drosophila-simulans_CM000363.lin.EMBL_RF00028_Intron_gpI_1349111823_23352_8_1</file_name>
  <error_code>-161</error_code>
</file_xfer_error>

Hier die T4T: wu_1378991704_42373_0
Bei der ist die Ausgabe für mich reichlich unübersichtlich, vielleicht kann ja einer der Programmierer hier da was mit anfangen.

Ich habe beide VBoxes im VBox-Manager mit Sicherung angehalten, aber ein versuchter Neustart ging nicht. Vermutlich wurde der Slot beim Melden der Wutzen gelöscht, da habe ich nicht dran gedacht.
Beide VBoxes haben jedenfalls munter gerechnet und nach Systemüberwachung jeweils ca. 25% meines 4-Kerners belegt, während die anderen 4 Wutzen sich mit den verbliebenen 50% begnügen mussten.

Edith sagt:
Bevor ich die beiden Projekte auf NNW gesetzt habe (unbeaufsichtigt sollten die im Moment wohl eher nicht laufen), hat sich RNA eine neue Wutz geladen, und die steht jetzt nach 10min auf 98,765%, ein Stand, den ich bei anderen Wutzen auch schon über einen sehr langen Zeitraum ohne jede Änderung gesehen habe. Da die bislang (von meinen Wingmen) eher schlecht berechnet wurde, habe ich sie mal angehalten, was sie im VBox-Manager auch prompt auf "Ausgeschaltet" gesetzt hat. Heut' Abend werd' ich sie wieder einschalten und mehr berichten.

[ChristianB]

Die zwei habe ich auch schon gesehen. Keine Ahnung warum die VM nach so kurzer Zeit runtergefahren ist. Eventuell braucht die VM mehr Speicher und hat deshalb angehalten aber der vboxwrapper hat das nicht mitbekommen.

[Matthias Lehmkuhl]

Leider konnte ich gestern Abend keine Antwort schreiben. Nach erfolgreicher Anmeldung bin ich anstelle zum Thema wieder im Anmeldefenster gelandet.

Ich habe gestern folgendes Problem gehabt.
Zwei cmsearch VM wrapper 1.03 Tasks wurden mit Fehler beendet, aber die VBoxHeadles Prozesse für die WU waren 2 Stunden später immer noch aktiv.
http://www.rnaworld.de/rnaworld/result. ... d=14920907
http://www.rnaworld.de/rnaworld/result. ... d=14920911
Der 3. Task lief noch.
Ein beenden des boinc client hat die laufenden VBoxHeadles Prozesse auch nicht beendet.
Mit dem VirtualBox Manager konnte ich die beiden VM dann beenden, aber nur per hartem Power Off.

Zusätzlich ist mir aufgefallen, das die Einträge in der VirtualBox.xml nicht mehr entfernt werden.
Auszug aus der VirtualBox.xml
<MachineEntry uuid="{890e53a9-7d48-4291-be97-d299f2289de0}" src="D:\Public\BOINCdata\slots\5\boinc_wu_1378991704_9924_0\boinc_wu_1378991704_9924_0.vbox"/>
<MachineEntry uuid="{bea584f1-45fb-4736-84b4-5fe37c79651b}" src="D:\Public\BOINCdata\slots\12\boinc__slot_12\boinc__slot_12.vbox"/>
<MachineEntry uuid="{fd086727-1c8d-4f1c-ae1d-e7ac46a1360c}" src="D:\Public\BOINCdata\slots\8\boinc__slot_8\boinc__slot_8.vbox"/>
<MachineEntry uuid="{27686e85-0d85-4e61-b973-618da932742c}" src="D:\Public\BOINCdata\slots\15\boinc__slot_15\boinc__slot_15.vbox"/>
Für diese Einträge gibt es in den slots keine Dateien mehr.

Eventuell kommt folgender Fehler auch daher.
http://www.rnaworld.de/rnaworld/result. ... d=14921252
VBoxManage.exe: error: Medium 'E:\Public\BoincData\slots\2\vm_image.vdi' is not accessible. UUID {e5d89a57-c0eb-4cc0-ae23-44dc9f1f80ea} of the medium 'E:\Public\BoincData\slots\2\vm_image.vdi' does not match the value {13677cac-c315-4985-bdb9-4dfd11264f70} stored in the media registry ('C:\Users\Matthias/.VirtualBox\VirtualBox.xml')

Diese Fehler habe ich vor cmsearch VM wrapper 1.03 noch nicht gesehen.

[ChristianB]

Leider konnte ich gestern Abend keine Antwort schreiben. Nach erfolgreicher Anmeldung bin ich anstelle zum Thema wieder im Anmeldefenster gelandet.

Ich habe gestern folgendes Problem gehabt.
Zwei cmsearch VM wrapper 1.03 Tasks wurden mit Fehler beendet, aber die VBoxHeadles Prozesse für die WU waren 2 Stunden später immer noch aktiv.
http://www.rnaworld.de/rnaworld/result. ... d=14920907
http://www.rnaworld.de/rnaworld/result. ... d=14920911
Der 3. Task lief noch.
Ein beenden des boinc client hat die laufenden VBoxHeadles Prozesse auch nicht beendet.
Mit dem VirtualBox Manager konnte ich die beiden VM dann beenden, aber nur per hartem Power Off.

Zusätzlich ist mir aufgefallen, das die Einträge in der VirtualBox.xml nicht mehr entfernt werden.
Auszug aus der VirtualBox.xml
<MachineEntry uuid="{890e53a9-7d48-4291-be97-d299f2289de0}" src="D:\Public\BOINCdata\slots\5\boinc_wu_1378991704_9924_0\boinc_wu_1378991704_9924_0.vbox"/>
<MachineEntry uuid="{bea584f1-45fb-4736-84b4-5fe37c79651b}" src="D:\Public\BOINCdata\slots\12\boinc__slot_12\boinc__slot_12.vbox"/>
<MachineEntry uuid="{fd086727-1c8d-4f1c-ae1d-e7ac46a1360c}" src="D:\Public\BOINCdata\slots\8\boinc__slot_8\boinc__slot_8.vbox"/>
<MachineEntry uuid="{27686e85-0d85-4e61-b973-618da932742c}" src="D:\Public\BOINCdata\slots\15\boinc__slot_15\boinc__slot_15.vbox"/>
Für diese Einträge gibt es in den slots keine Dateien mehr.

Eventuell kommt folgender Fehler auch daher.
http://www.rnaworld.de/rnaworld/result. ... d=14921252
VBoxManage.exe: error: Medium 'E:\Public\BoincData\slots\2\vm_image.vdi' is not accessible. UUID {e5d89a57-c0eb-4cc0-ae23-44dc9f1f80ea} of the medium 'E:\Public\BoincData\slots\2\vm_image.vdi' does not match the value {13677cac-c315-4985-bdb9-4dfd11264f70} stored in the media registry ('C:\Users\Matthias/.VirtualBox\VirtualBox.xml')

Diese Fehler habe ich vor cmsearch VM wrapper 1.03 noch nicht gesehen.

Das mit den laufenden Prozessen ist sehr ärgerlich und ich wüsste auch gern warum der vboxwrapper die nicht abbricht. Rom hatte extra für den 1.03 wrapper daran geschraubt. Die übriggebliebenen Einträge in der VirtualBox.xml sind Rom auch schon aufgefallen und bereits im Code behoben.

[Michael H.W. Weber]

Für die aktuellen von XXL konvertierten VM Jobs habe ich keinen neuen Forecast gemacht sondern den Wert einfach kopiert

..der wird aber wie erläutert defintiv nicht angezeigt, sondern eine Gesamtlaufzeit, die wesentlich darunter liegt (>Faktor 20).

Wie schon gesagt sollte er eigentlich nicht gleich auf 98,765% springen aber ich kann ja schlecht eine Prozentzahl auswürfeln und anzeigen.

Naja, was aber doch konsistent sein muss ist die Relation zwischen verbleibender Laufzeit und Fortschrittsanzeige. Wenn also eine WU gestartet wird, dann ist der Fortschritt Null und die Gesamtlaufzeit wird angezeigt. Wenn ich von ursprünglich 20 Std. 10 gerechnet habe, dann sollte der Fortschrittsbalken auf 50% stehen, nicht aber auf 98,765%.

Gut, ich verstehe natürlich, dass da noch was getan werden muss. Wollte nur die Dinge, die mir auffallen möglichst ausführlich hier posten. Also bitte nicht als Meckerei auffassen, auch wenn es manchmal so klingt.

Was ich jetzt noch nicht verstanden habe ist, inwieweit die Autoverlängerung funktioniert: Bislang musste ich ja selbst schauen, wo die Deadline liegt und dann lokal abgleichen und ggf. melden, wenn zuerwarten ist, dass die WU länger als die Deadline laufen wird. Wie wird das jetzt realisiert?

@Yoyo: Kannst Du Deinen Schleppkopp bitte nochmal mit (Zahl der Kerne minus 1) VM-WUs ausstaffieren und dann gucken, wie zäh die Kiste läuft, wenn (1) ein Kern komplett idle ist und (2) ein zweites DC-Projekt auch diesen einen Kern belegt? Was für eine CPU ist das?

@Plonk: RAM-Auslagerung auf Platte möglich als Ursache bei Dir?

Michael.

[ChristianB]

Für die aktuellen von XXL konvertierten VM Jobs habe ich keinen neuen Forecast gemacht sondern den Wert einfach kopiert

..der wird aber wie erläutert defintiv nicht angezeigt, sondern eine Gesamtlaufzeit, die wesentlich darunter liegt (>Faktor 20).

Das liegt daran das die Restlaufzeit vom Client anhand der geschätzten FLOPs und des aktuellen Fortschritts berechnet wird. Da haben wir keinen direkten Einfluß drauf. Wir geben ja keine Laufzeit an den Job sondern die geschätzte Anzahl an FLOPs, die dann wiederum der Client anhand der Benchmarks des Hosts in eine Laufzeit umrechnet. Und der verlässt sich darauf das er einigermaßen ordentliche Werte von der Anwendung bekommt.

Wie schon gesagt sollte er eigentlich nicht gleich auf 98,765% springen aber ich kann ja schlecht eine Prozentzahl auswürfeln und anzeigen.

Naja, was aber doch konsistent sein muss ist die Relation zwischen verbleibender Laufzeit und Fortschrittsanzeige. Wenn also eine WU gestartet wird, dann ist der Fortschritt Null und die Gesamtlaufzeit wird angezeigt. Wenn ich von ursprünglich 20 Std. 10 gerechnet habe, dann sollte der Fortschrittsbalken auf 50% stehen, nicht aber auf 98,765%.

Das ist ja gerade das Hauptproblem es ist schwierig die Prozentanzeige von cmsearch zu bekommen. Und warum bei diesen konvertierten jetzt die Laufzeitschätzung so weit unten ist kann ich auch nicht sagen. Eventuell denkt cmsearch das es mit SSE3 viel schneller ist als in Wirklichkeit. Ich habe auch keine Erklärungen dafür aber so funktioniert das System nunmal. Wenn ich aktuell mehr Zeit hätte dann würde ich auch noch einen genaueren Blick auf diese neuen Aufgaben werfen aber leider machen sich die Hausaufgaben nicht von alleine.

Was ich jetzt noch nicht verstanden habe ist, inwieweit die Autoverlängerung funktioniert: Bislang musste ich ja selbst schauen, wo die Deadline liegt und dann lokal abgleichen und ggf. melden, wenn zuerwarten ist, dass die WU länger als die Deadline laufen wird. Wie wird das jetzt realisiert?

Der vboxwrapper löst alle 4 Stunden Laufzeit eine trickle_up Nachricht aus die dann vom Client an den Server geschickt wird. Auf dem Server läuft ein Tool (trickle_deadline) welches diese Nachricht auswertet und bei Bedarf die Aufgabe verlängert. Solange der Rechner also einen Netzwerkzugang hat und sich innerhalb von 14 Tagen immer mal wieder beim Server meldet ist alles in Ordnung.

[Bommer]

Hurra.

Endlich funktioniert es auch bei mir.... Mal sehen, was dabei so rauskommt. Gleich mal eine mit über 1500 h erhalten.

Gruss Bommer

[Michael H.W. Weber]

@Christian: Danke erstmal für die Infos. Ich denke, wir müssen in die Fortschrittsbalken- und Lauzeitvorhersageproblematik nochmal komplett neu und detaillierter einsteigen, evt. auch mit einem neuen Ansatz. Aber lass Dir Zeit.

Michael.

[Sightus@CAU]

Kann bzw. sollte man noch einsteigen? Wenn ja, dann hätte ich noch ein paar Fragen

[ChristianB]

Die jetzigen VM Aufgaben sind recht anspruchsvoll was die Zeit angeht aber wenn es läuft dann läuft es. Die cmsearch VM ist jetzt für alle geöffnet und ich werde irgendwann die ganzen Logfiles mal nach Berkeley weiterleiten. Obwohl das recht wenig hilfreich ist, da man da nicht so wirklich die Ursache der Fehler sehen kann.

Deine Fragen kannst du natürlich immer stellen.

[Beorn]

Jacob Klein hat im Newsbereich einige interessante Informationen zusammengetragen, die erklären weshalb der von den RNA VMs insgesamt belegte Speicher viel höher ist, als z.B. in der Prozessübersicht für die Summe der einzelnen Prozesse aufgelistet (wie auch hier schon berichtet wurde). Da BOINC sich bisher offensichtlich auf den zu niedrigen Wert 'verläßt', würde der Rechner in der Folge bei mehreren parallel gestarteten VMs, wie ebenfalls schon berichtet, zäh in der Bedienung durch das auftretende Paging. Offensichtlich hat man bei den BOINC-Devs schon einen Lösungsansatz.

Noch etwas Negatives (aus meiner Sicht): Auch auf meinem dritten Rechner ist jetzt nach rund 57.000 Sek. Berechnungszeit das Problem der schnell anwachsenden stderr.txt aufgetreten. Damit ist für mich ein Hardwarefehler als Auslöser sehr unwahrscheinlich geworden, da die drei Rechner alles andere als baugleich sind.

Gruß

[Crystal Pellet]

. . . und ich werde irgendwann die ganzen Logfiles mal nach Berkeley weiterleiten. Obwohl das recht wenig hilfreich ist, da man da nicht so wirklich die Ursache der Fehler sehen kann.

Inzwischen hat Rom neue Versionen vom wrapper kompiliert für alle Operating Systeme -> vboxwrapper 26029.

Ich bin mir aber nicht sicher was er da repariert hat. Ich habe die 2 Windows 26029-versionen bei T4T getested und die 26029 läuft ohne crash,
aber das sagt nicht viel aus, denn auch mit älteren wrappers hatte ich eigentlich nie Probleme.