Falten in einer VM, fertige WU wird nicht gesendet, neue WU wird nicht erhalten

ADGMike

F@H-Team-Member (m/w)
Tja, das ist jetzt die 3. oder 4. fertige WU, die für alle Beteiligten umsonst war :/
Ich falte mit WIN7 64 in der VM ( siehe Argead thread http://extreme.pcgameshardware.de/f...ow-schnell-effizient-falten-mit-einer-vm.html ), jedoch wenn 100% erreicht sind wird sie weder vom server angenommen, noch erhalte ich umgehend eine neue. Beim letzten Mal kam ca. 2 Tage keine neue WU, dann jedoch ohne Veränderung meinerseits erhielt ich wieder eine.

[03:49:56] Completed 250000 out of 250000 steps (100%)
[03:50:12] DynamicWrapper: Finished Work Unit: sleep=10000
[03:50:22]
[03:50:22] Finished Work Unit:
[03:50:22] - Reading up to 52544928 from "work/wudata_04.trr": Read 52544928
[03:50:22] trr file hash check passed.
[03:50:22] - Reading up to 46179772 from "work/wudata_04.xtc": Read 46179772
[03:50:23] xtc file hash check passed.
[03:50:23] edr file hash check passed.
[03:50:23] logfile size: 205243
[03:50:23] Leaving Run
[03:50:26] - Writing 99094859 bytes of core data to disk...
[03:50:32] - Could not write to results file.
[03:50:32] - Error: Could not write out results to file
[03:50:32] - Shutting down core
[03:50:32]
[03:50:32] Folding@home Core Shutdown: FILE_IO_ERROR
[03:53:47] CoreStatus = 64 (100)
[03:53:47] Unit 4 finished with 62 percent of time to deadline remaining.
[03:53:47] Updated performance fraction: 0.623781
[03:53:47] Sending work to server
[03:53:47] Project: 2683 (Run 0, Clone 14, Gen 60)


[03:53:47] + Attempting to send results [April 5 03:53:47 UTC]
[03:53:47] (Read 114688 bytes from disk)
[03:53:47] Connecting to http://171.67.108.22:8080/
[03:53:47] - Couldn't send HTTP request to server
[03:53:47] + Could not connect to Work Server (results)
[03:53:47] (171.67.108.22:8080)
[03:53:47] + Retrying using alternative port
[03:53:47] Connecting to http://171.67.108.22:80/
[03:53:47] - Couldn't send HTTP request to server
[03:53:47] + Could not connect to Work Server (results)
[03:53:47] (171.67.108.22:80)
[03:53:47] - Error: Could not transmit unit 04 (completed April 5) to work server.
[03:53:47] Keeping unit 04 in queue.
[03:53:59] Trying to send all finished work units
[03:53:59] Project: 2683 (Run 0, Clone 14, Gen 60)


[03:53:59] + Attempting to send results [April 5 03:53:59 UTC]
[03:53:59] (Read 114688 bytes from disk)
[03:53:59] Connecting to http://171.67.108.22:8080/
[03:53:59] - Couldn't send HTTP request to server
[03:53:59] + Could not connect to Work Server (results)
[03:53:59] (171.67.108.22:8080)
[03:53:59] + Retrying using alternative port
[03:53:59] Connecting to http://171.67.108.22:80/
[03:53:59] - Couldn't send HTTP request to server
[03:53:59] + Could not connect to Work Server (results)
[03:53:59] (171.67.108.22:80)
[03:53:59] - Error: Could not transmit unit 04 (completed April 5) to work server.

Any idea ?
Es kann doch nicht sein, dass immer wenn ich eine fertig habe, der server ein Päusschen macht, oder ... ?
 
Dass die Workserver öfter mal nicht verfügbar sind, ist keine Ausnahme. Allerdings sollte der Client den Upload noch vor der deadline schaffen. Generelle Probleme mit dem Internet hast Du zum Upload-Zeitpunkt wahrscheinlich nicht ?
Hast Du den Langouste De-coupler aktiviert ? Das ist quasi ein lokaler Proxy, welcher den Versand der fertigen Projekte im Hintergrund organisiert und den Folding-Client sofort zum Laden eines neuen Projektes "überrredet". Allerdings sieht man den erfolgreichen Upload im Client-Protokoll nur indirekt, wenn dieser später selbst versucht, ein Projekt hochzuladen, welches vom Langouste De-coupler bereits erledigt wurde (s. meinen Beitrag hier http://extreme.pcgameshardware.de/f...zient-falten-mit-einer-vm-10.html#post1461184).
 
Jau, connect-probs dürften es nicht sein und Langouste DE-coupler ist mit einem Häkchen versehen.
Ich kann mir ja das .log-file anschauen.
hmm, kann die VM zu klein ( HD - Platzmangel ) bemessen sein ? Ich hatte sie direkt übernommen.
Nun habe ich versucht mit -send all wenigstens die aktuelle zu retten, aber :
 
Sieh Dir erstmal die Langouste-Protokolle an. Normalerweise kann der Client nicht mehr senden, das das der De-coupler übernimmt. Und dann würde ich im Web-Browser mal die Work-Server-Adressen testen.

Habe gerade die Meldung mit FILE_IO_ERROR gesehen. Wie stark hast Du die CPU OC'ed (s.a. http://www.overclock.net/overclock-net-folding-home-team/230439-smp-file-i-o-error.html) ? Gib mal in der Console df ein und poste den Screenshot, sowie top (beenden mit Eingabe q) und poste den Srceenshot auch. Am besten, Du postest auch noch den Screenshot vom Web-Configuration-Tool der VM.
 
Zuletzt bearbeitet:
Thx für die Ideen und Hilfestellung @Mattinator.
oc ist minimal, der i7 965 läuft auf x28 das macht 3,729 GHz, keine V Erhöhung o.ä. .
Den client habe ich mittlerweile beendet.
 
Das sieht irgendwie stark danach aus als sei dir der Platz ausgegangen wenn man sich die df ausgabe ansieht.
Es würde auch erklären warum der Core normal beendet wurde aber die Ergebnisse nicht schreiben konnte.
 
Das sieht irgendwie stark danach aus als sei dir der Platz ausgegangen wenn man sich die df ausgabe ansieht.
Es würde auch erklären warum der Core normal beendet wurde aber die Ergebnisse nicht schreiben konnte.

Stimmt genau, das Root-Filesystem ist voll. Wenn ich mich richtig erinnere, wird bei aktivierter Ramdisk bei jedem Beenden ein Backup des Folding-Ordners gemacht. Das müsste sicher mal manuell aufgeräumt werden, lässt sich jedoch hier über's Forum schlecht unterstützen. Ich hatte bei mir die Ramdisk deaktiviert, da der Geschwindigkeitsvorteil nur marginal ist.
 
Ich habe das gesamte f&h Verzeichnis sowie die Verknüpfung in der vm gelöscht.
Neue Verknüpfung erstellt, seit dem rennt alles tiptop.
Ich denke mal die Wichtigste Veränderung, die ich vorgenommen habe ist:
kein Stop per webadmin, sondern ausschlieslich in der vm-linux Maske mit
"shutdown -h now"
Beim nächsten Start der vm läuft alles einwandfrei - na gut, 1 x hat er die Arbeit nicht aufnehmen können, quasi 1 WU verloren, aber Ausnahmen bestätigen bekanntlich die Regel.
 
Zurück