offener Betatest für neue cmsearch VM Anwendung

Alles zum Projekt RNA World
Nachricht
Autor
Benutzeravatar
Uwe Sänger Herzke
Block-Bunkerer
Block-Bunkerer
Beiträge: 1326
Registriert: 31.05.2006 14:33
Wohnort: Bremen
Kontaktdaten:

Re: offener Betatest für neue cmsearch VM Anwendung

#217 Ungelesener Beitrag von Uwe Sänger Herzke » 23.10.2013 05:50

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.
Grüße vom Sänger
Bild Bild Bild

ChristianB
Vereinsvorstand
Vereinsvorstand
Beiträge: 1915
Registriert: 23.02.2010 22:12

Re: offener Betatest für neue cmsearch VM Anwendung

#218 Ungelesener Beitrag von ChristianB » 23.10.2013 07:50

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
Prozessor-Polier
Prozessor-Polier
Beiträge: 125
Registriert: 12.03.2008 20:42

Re: offener Betatest für neue cmsearch VM Anwendung

#219 Ungelesener Beitrag von Matthias Lehmkuhl » 23.10.2013 07:56

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

Bild - Bild

ChristianB
Vereinsvorstand
Vereinsvorstand
Beiträge: 1915
Registriert: 23.02.2010 22:12

Re: offener Betatest für neue cmsearch VM Anwendung

#220 Ungelesener Beitrag von ChristianB » 23.10.2013 08:18

Matthias Lehmkuhl hat geschrieben: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.

Benutzeravatar
Michael H.W. Weber
Vereinsvorstand
Vereinsvorstand
Beiträge: 20833
Registriert: 07.01.2002 01:00
Wohnort: Marpurk
Kontaktdaten:

Re: offener Betatest für neue cmsearch VM Anwendung

#221 Ungelesener Beitrag von Michael H.W. Weber » 23.10.2013 10:35

ChristianB hat geschrieben: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).
ChristianB hat geschrieben: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. :D

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.
Fördern, kooperieren und konstruieren statt fordern, konkurrieren und konsumieren.

http://signature.statseb.fr I: Kaputte Seite A
http://signature.statseb.fr II: Kaputte Seite B

Bild Bild Bild

ChristianB
Vereinsvorstand
Vereinsvorstand
Beiträge: 1915
Registriert: 23.02.2010 22:12

Re: offener Betatest für neue cmsearch VM Anwendung

#222 Ungelesener Beitrag von ChristianB » 23.10.2013 12:13

Michael H.W. Weber hat geschrieben:
ChristianB hat geschrieben: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.
Michael H.W. Weber hat geschrieben:
ChristianB hat geschrieben: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.
Michael H.W. Weber hat geschrieben: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.

Benutzeravatar
Bommer
WU-Schieber
WU-Schieber
Beiträge: 1181
Registriert: 24.06.2001 01:00

Re: offener Betatest für neue cmsearch VM Anwendung

#223 Ungelesener Beitrag von Bommer » 23.10.2013 12:17

Hurra.

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

Gruss Bommer

Benutzeravatar
Michael H.W. Weber
Vereinsvorstand
Vereinsvorstand
Beiträge: 20833
Registriert: 07.01.2002 01:00
Wohnort: Marpurk
Kontaktdaten:

Re: offener Betatest für neue cmsearch VM Anwendung

#224 Ungelesener Beitrag von Michael H.W. Weber » 23.10.2013 13:18

@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. :D

Michael.
Fördern, kooperieren und konstruieren statt fordern, konkurrieren und konsumieren.

http://signature.statseb.fr I: Kaputte Seite A
http://signature.statseb.fr II: Kaputte Seite B

Bild Bild Bild

Sightus@CAU
PDA-Benutzer
PDA-Benutzer
Beiträge: 34
Registriert: 15.04.2013 13:39

Re: offener Betatest für neue cmsearch VM Anwendung

#225 Ungelesener Beitrag von Sightus@CAU » 23.10.2013 20:24

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

ChristianB
Vereinsvorstand
Vereinsvorstand
Beiträge: 1915
Registriert: 23.02.2010 22:12

Re: offener Betatest für neue cmsearch VM Anwendung

#226 Ungelesener Beitrag von ChristianB » 23.10.2013 21:15

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

Re: offener Betatest für neue cmsearch VM Anwendung

#227 Ungelesener Beitrag von Beorn » 24.10.2013 11:55

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

Re: offener Betatest für neue cmsearch VM Anwendung

#228 Ungelesener Beitrag von Crystal Pellet » 24.10.2013 17:26

ChristianB hat geschrieben:. . . 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.

Antworten

Zurück zu „RNA World Diskussionen (deutsch)“