offener Betatest für neue cmsearch VM Anwendung

[Michael H.W. Weber]

Meiner ungefragte Meinung nach liegt es nicht am Architektur aber am wrapper und Speicherbedarf.
Michael hat maximal 6-7 GB verfügbar und hat drei Aufgaben. Jede VM möchte 4GB reservieren.
Ich habe mit meiner einstige Aufgabe Null Probleme, obwohl ich die Aufgabe mindestens einmal am Tag anhalte und nicht im Speicher verwahre.
Manchmal BOINC abschliese oder sogar den PC neustarte AMD Phenom 9350e Quad mit 8GB memory.
Darauf laufen auch noch BOINC VM's für T4T und climateathome.

Nö, die Diagnose muss so nicht stimmen, denn ich berichtete ja, dass auch die Einzelaufgabe krepierte nach Managerneustart. Zudem war das Neustarten auf dem Intel Null Problem mit 3 VMs und 8 GB physikalischem RAM.
Ob jeden VM 4 GB RAM reserviert, ist mir auch unklar. Bei mir tut sie das definitiv nicht.

Michael.

[Crystal Pellet]

Meiner ungefragte Meinung nach liegt es nicht am Architektur aber am wrapper und Speicherbedarf.
Michael hat maximal 6-7 GB verfügbar und hat drei Aufgaben. Jede VM möchte 4GB reservieren.
Ich habe mit meiner einstige Aufgabe Null Probleme, obwohl ich die Aufgabe mindestens einmal am Tag anhalte und nicht im Speicher verwahre.
Manchmal BOINC abschliese oder sogar den PC neustarte AMD Phenom 9350e Quad mit 8GB memory.
Darauf laufen auch noch BOINC VM's für T4T und climateathome.

Nö, die Diagnose muss so nicht stimmen, denn ich berichtete ja, dass auch die Einzelaufgabe krepierte nach Managerneustart. Zudem war das Neustarten auf dem Intel Null Problem mit 3 VMs und 8 GB physikalischem RAM.
Ob jeden VM 4 GB RAM reserviert, ist mir auch unklar. Bei mir tut sie das definitiv nicht.

Michael.

Etwas weiter in meinem Beitrag stand ja auch das der wrapper das Hauptproblem ist.

Die volle 4GB werden wahrscheinlich nicht direkt ganz vom verfürbaren Speicher abgezogen.
Ich habe mal meine RNA-Aufgabe angehalten und neu gestartet. Speicherbedarf stieg um ungefähr 1.3 GB.

[Beorn]

Jetzt geht die RNA Wutze vom 10.10. auch in 'Hohe Priorität' weil mein BOINC natürlich nicht weiß, dass serverseitig die Deadline bereits auf den 29. November verlängert wurde

Ok, ist mir jetzt doch gelungen, dass Ablaufdatum auch im BOINC auf dem Client zu verändern, k.A. warum es beim ersten Mal nicht klappte. BM stoppen, client_state.xml öffnen und im betreffenden <result> Abschnitt den Wert im Tag <report_deadline> entsprechend ändern (der numerische Wert ist gleich der Summe der Sekunden zwischen dem 01.01.1970 und Tag/Uhrzeit des Ablaufdatums). Dann BM wieder starten. So spart man sich den leidigen und hier unnötigen Panikmodus.

[ChristianB]

Es gab einen Fehler bei der Konvertierung der XXL zu VM Aufgaben. Es liegt nicht an der Anwendung sondern an den Eingabedaten für das Kontrollskript. Das ist auch der Grund warum die Fortschrittsanzeige nicht geht. Die eigentliche Berechnung sollte trotzdem laufen. Ich werde für die bereits angehaltenen Aufgaben das korrigieren und neue Aufgaben erzeugen, soweit das Möglich ist.

Wer aktuell noch Probleme auf seinem Rechner hat. Eventuell immer größer werdende stderr.txt oder Performanceeinbrüche kann ohne schlechtes Gewissen die Aufgabe abbrechen!

[Beorn]

Danke für die Info. Da ich bereits 45 Tage Rechenzeit in die Pakete 6330532, 6330673, 6330719, 6330731, 6330742, 6330745, 6330753, 6330760, 6330761 und 6330768 gesteckt habe, will ich nun wenigstens mal abwarten, bis die erste Wutze fertig ist und schauen ob die ordentlich beendet und hochgeladen wird. Dann schau'n mer weiter.

[Beorn]

Guten Morgen. Konnte jemand bereits eine cmsearch VM Workunit aus den am 20.10. erzeugten Paketen erfolgreich abschließen?

Meine Workunit aus Paket 6330753 erreicht heute 100% der geschätzten Rechenzeit auf dem Referenzsystem. Die Anfang Oktober berechneten, insgesamt 52 kurzen Testwutzen benötigten auf gleichem System jedoch nur rund 60%.

EDIT 16:18 Uhr: Tja, immer noch kein Ende in Sicht. Skepsis steigt.

Code: Alles auswählen

2013-11-01 15:50:00 (manual): content deleted to limit file size
2013-11-01 15:56:45 (3876): vboxwrapper: starting
2013-11-01 15:56:45 (3876): Feature: Enabling trickle-ups (Interval: 14400.000000)
2013-11-01 15:56:45 (3876): Detected: VirtualBox 4.2.16r86992
2013-11-01 15:56:47 (3876): Restore from previously saved snapshot.
2013-11-01 15:56:48 (3876): Restore completed.
2013-11-01 15:56:48 (3876): Starting VM.
2013-11-01 15:57:03 (3876): Successfully started VM.
2013-11-01 15:57:03 (3876): Setting cpu throttle for VM. (100%)
2013-11-01 16:07:13 (3876): Status Report: Job Duration: '0.000000', Elapsed Time: '769658.918069', Network Bytes Sent (Total): '0.000000', Network Bytes Received (Total): '0.000000'
2013-11-01 16:07:13 (3876): Creating new snapshot for VM.
2013-11-01 16:07:18 (3876): Deleting stale snapshot.
2013-11-01 16:07:18 (3876): Checkpoint completed.
2013-11-01 16:17:24 (3876): Creating new snapshot for VM.
2013-11-01 16:17:28 (3876): Deleting stale snapshot.
2013-11-01 16:17:29 (3876): Checkpoint completed.

P.S.: Euer Forum ist noch in der Sommerzeit.

[Michael H.W. Weber]

Ja, ich fände es gut, wenn es dann wieder Test-WUs gäbe, damit wir weitere "bugs" (hoffentlich nicht mehr) finden können.

Michael.

[Dunuin]

http://www.rnaworld.de/rnaworld/result. ... d=14920944
Woran hat es gelegen? Platte voll? Mochte die PC-Abstürze nicht? Hatte schon 5 Tage Rechenzeit oder so auf dem Buckel *seufts*

[Beorn]

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.

Eine Nachfrage zur Autoverlängerung: Wann wird die Ablauffrist der Aufgaben verlängert, gibt es da einen festen Wert wie z.B. 2 Tage vor Ablauf, an dem das serverseitige Tool reagiert? Ich warte noch auf ein fertiges Ergebnis und habe momentan folgende Wutzen (mit Autoverlängerung) in Arbeit, die alle in vier Tagen ablaufen würden nach derzeitiger Frist:

Paket / bisherige Rechenzeit (Vergleich Ref.-syst.) / Flügelmann noch vorhanden
6330742 / 3% / ja
6330753 / 138% / ja
6330760 / 15% / ja
** siehe edit unten *** 6330761 / 104% / ja
6330768 / 54% / nein
6330745 / 45% / ja
6330731 / 3% / nein
6330719 / 1% / ja

Danke vorab und Schönen Feierabend!

EDIT: Wie schon im engl. Forenthread geschrieben, die Wutze zu Packet 6330761 wurde soeben beendet und zwar zunächst einmal erfolgreich. Bin jetzt natürlich gespannt wie ein Flitzebogen, ob was Brauchbares angekommen ist. Der Flügelmann ist noch unterwegs.

[ChristianB]

Ich habe jetzt erstmal alle 130 laufenden Aufgaben per Hand verlängert. Die automatische Verlängerung an sich funktioniert aber anscheinend senden eure Clients keine Trickles mehr und deshalb wird auch nichts verlängert. Bitte mal heute oder morgen im Manager auf Aktualisieren klicken. Ich hoffe das dann ein paar neue Trickles eintreffen und ich etwas besser die Ursache verstehe.

[Beorn]

Bitte mal heute oder morgen im Manager auf Aktualisieren klicken.

Done. Mir ist aufgefallen, dass alle o.g. Pakete bzw. Wutzen von mir um genau einen Monat verlängert wurden, jedoch Paket 6330742 / Aufgabe 14920804 nur um 14 Tage. Vermute mal, in einem der beiden Fälle hat das serverseitige Tool funktioniert? Vllt. hilft's bei der Analyse. Gute Nacht!

P.S.: Nettes Homework, die neuen Fristen in die client_state.xmls einzupflegen... (vllt. noch'n feature request an die Devs in Berkeley? )

[Beorn]

Willkommen im Club! Habe heute morgen auch eine Wutze nach Neustart verloren mit dem bekannten "already locked by a session"-Fehler:

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

Mögliche Unterschiede zu den bisherigen, zahllosen Neustarts ohne Probleme:

- die stderr.txt hatte zuvor über 500 MB Größe erreicht, wurde jedoch vor dem Neustart gelöscht (bzw. mit leerer Datei überschrieben) -> unwahrscheinliche Ursache?
- ich hatte relativ zügig nach Beendigung von BM und Anwendungen neu gestartet, lt. Taskmanager waren alle VM-Prozesse außer VBoxSVC.exe jedoch beendet -> hatte vlt. VBoxSVC.exe die VM noch nicht freigegeben?

Alles nur Gedankenspiele, letztlich bleibt mir die Fehlerursache rätselhaft.