Docking@Home - Wir haben ein Team

Hat jemand schlechte Erfahrungen mit den aktuellen Wus gemacht?
Ich habe nun schon 4 Stück bekommen, die nach 12h immer noch bei 0% waren, obwohl eine geschätzte Laufzeit bei weniger als der Hälfte lag:
http://docking.cis.udel.edu/community/result.php?resultid=10324352
http://docking.cis.udel.edu/community/result.php?resultid=10324351
http://docking.cis.udel.edu/community/result.php?resultid=10324349
http://docking.cis.udel.edu/community/result.php?resultid=10315645

Bisher hatte ich mit meinem Quad noch keine Probleme bei Docking. Bis auf weiteres werde ich wieder was anderes rechnen

Ich schaffe es z.B. nicht, egal wie sehr ich mich auf den Kopf stelle, meinen Q9650 mit Win7 unter Docking zum Laufen zu bringen. Dieser bleibt immer bei 0% "hängen". Im Forum gab/gibts ähnliche Meldungen. Man weiß es aber nicht woran es liegt.
 
hab jetzt ein paar WUs für Docking gerechnet, dabei ist mir aufgefallen, dass Docking als 32 bit Anwendung laut Taskmanager läuft (*32 steht an dem Prozess). Ich nutze Win7 64 bit und habe den Boinc Client 6.10.18 in der 64 bit Version am laufen. Der Prozess mit dem die Berechnungen laufen heißt charmm34_6.23_windows_x86_64. Deswegen dachte ich er würde auch im 64 bit Modus laufen. Irgendwie widerspricht sich das.

Kann mich jemand aufklären?

Um mal darauf zurück zu kommen...hier ist die Antwort: -> http://docking.cis.udel.edu/community/forum/thread.php?id=233

-----------------------------

Hab grad festgestellt, daß Docking leider auch eines der Projekte ist, das viel mehr leisten könnte. SSEx lassen die einfach mal komplett außen vor. :o

No cpu specific optimizations are utilized because the application has to run on so many different processors without crashing. And yes, this is a restriction, but hardly one that can be avoided in a boinc project.


Ich dachte immer, das prüft die Anwendung dann "ganz einfach"...so wie es z.B. bei Folding@home seit jeher der Fall ist!?
 
meines wissens ist nur der Intel Compiler dazu in der Lage die unterstützten Erweiterungen abzufragen und dann unterschiedlichen branches zu folgen.
 
meines wissens ist nur der Intel Compiler dazu in der Lage die unterstützten Erweiterungen abzufragen und dann unterschiedlichen branches zu folgen.

Und was glaubst du, mit was die wohl kompilieren? *suspect*
 
meines wissens ist nur der Intel Compiler dazu in der Lage die unterstützten Erweiterungen abzufragen und dann unterschiedlichen branches zu folgen.

soweit muss es garnicht kommen. Der Boinc-Manager meldet dem Projekt welche Erweiterungen die CPU unterstützt. Man müßte es eben nur noch benutzen, und da scheitert es atm.
.
EDIT :
.

Und was glaubst du, mit was die wohl kompilieren? *suspect*

Das Serviceprogramm [welches die Scripte abarbeitet] wurde einst mit einem IntelFortran-Compiler übersetzt, auf den Source hat man derzeit keinen Zugriff. Deshalb sind vorerst keine speziellen Optimierungen zu erwarten.
 
Der Boinc-Manager meldet dem Projekt welche Erweiterungen die CPU unterstützt.

Jap, das außerdem.


Das Serviceprogramm [welches die Scripte abarbeitet] wurde einst mit einem IntelFortran-Compiler übersetzt, auf den Source hat man derzeit keinen Zugriff. Deshalb sind vorerst keine speziellen Optimierungen zu erwarten.

Keinen Source-Zugriff? *chatt*

Welche Skripte? Heißt das, wenn die Anwendung nen Bug hat, kann man auch nichts machen?
 
Das wäre eine logische Konsequenz. [Die Infos habe ich von einem der Projekt-verantwortlichen]

Achja mit "Zugriff" ist wohl eher gemeint das man atm nicht in der Lage ist, an diesem Programm etwas zu ändern [obs am Quellcode liegt oder am fehlenden Wissen diesen zu verändern, weil der verantwortliche nicht mehr da ist, ka. das hat man mir nicht genau veraten]
 
Zuletzt bearbeitet:
Wer einmal gesehen hat was ein Fortranübersetzer für einen C-Code generiert wird auch verstehen warum das nicht so einfach ist...

Die Hälfte des Codes besteht nämlich aus GOTOs und es ist eine Höllenarbeit überhaupt zu verstehen was der Code macht, geschweige denn den neu zu schreiben.
 
Wer einmal gesehen hat was ein Fortranübersetzer für einen C-Code generiert wird auch verstehen warum das nicht so einfach ist...

Die Hälfte des Codes besteht nämlich aus GOTOs und es ist eine Höllenarbeit überhaupt zu verstehen was der Code macht, geschweige denn den neu zu schreiben.

Das liegt wie immer im Auge des Betrachters ;)
Jedenfalls wenn man sowas verwendet, sollte man auch in der Lage sein daran etwas zu verändern.
 
Wir haben hier auch 30 Jahre alten Code der von Fortran nach C übersetzt wurde - glaub mir du bist froh wenn der Kram rennt... Und Doku natürlich gleich Null.
 
Würde ich aber auch meinen...
 
das mag ja für _dich_ der Fall sein ;)

Erzähl das mal einem Chef der a) "kein Geld" hat b) "schnell fertig werden will" und c) "ich hab hier noch 10 andere Sachen für dich liegen"...

Interessehalber: schonmal für ein großes Projekt programmiert? Dann wüßtest du dass dort zwar Tausende von Stunden in die Ausarbeitung des Pflichtenhefts (wenn überhaupt..) und Hunderttausende Euro in Flugtickets investiert werden, die Programmierung dann aber am Besten in 2 Monaten fertig sein soll.
 
Nein ich spiele in der Arbeit im Sandkasten! Was für eine blöde Frage!
 
Ich schaffe es z.B. nicht, egal wie sehr ich mich auf den Kopf stelle, meinen Q9650 mit Win7 unter Docking zum Laufen zu bringen. Dieser bleibt immer bei 0% "hängen". Im Forum gab/gibts ähnliche Meldungen. Man weiß es aber nicht woran es liegt.

da sag ich mal gleiches Problem, Win7 64Bit und nen Q9550
 
schließe mich an ... mein Quad rechnet seit ca. 10Stunden und immer noch 0%
 
Ne kann nicht sein. Ich habe Win7 64bit und Docking und es läuft ohne Probleme.
 
also ein problem mit Win7+Docking?

nein würde ich so nicht sagen, ich habe noch zwei ähmliche [P45-Board+Penryn (6M)-CPU] Systeme mit Docking+Win7-64 am laufen. Im DockingForum und im SG Forum hab ich von ähnlichen Probleme gelesen. Und jedesmal war eine Penryn-CPU mit 12MB Cache dabei.
 
Zurück
Oben Unten