[ANN] F@H Console Monitor

[Gast]

So, ganz bestimmt die letzte ...

@Michael

kannst nach Stanford melden dass GROMACS auf nem Athlon MP(XP)
keine Assembler-Optimierungen meldet (durchführt?)

Code: Alles auswählen

Trying to unzip core FahCore_78.exe
Decompressed FahCore_78.exe (1564672 bytes) successfully
+ Core successfully engaged

+ Processing work unit
Core required: FahCore_78.exe (found)

[August 24 18:58:49] Working on Unit 09
+ Working ...
[18:58:49] Folding@Home Client Core Version 1.25 (August 19, 2002)
[18:58:49] 
[18:58:49] Proj: work/wudata_09

[18:58:49] No information on assembly optimizations.
*** Hier ------^^^^^^^^^^^^^^^^^^^^^^^^^^^^----***

Code: Alles auswählen

[18:58:49] Created dyn
[18:58:49] Files status OK
[18:58:49] Writing local files: 

Euler

[Michael H.W. Weber]

Ok. Bin schon gespannt auf den neuen fahMon.

Es sind übrigens seit gestern wieder einige, wenige GROMACS WUs im Umlauf. Der Grund ist, daß im Beta Tester Team bislang noch recht wenige Leute sind. Auch sind die zu testenden WUs Standard WUs - also meiner Meinung nach VIEL zu groß, um das Testen schnell voranzutreiben - habe es schon bemängelt. Daher benötigt Vijay wohl verstärkt Hilfe von anderen und gab eine kleine Menge der GROMACS WUs aus.

Die Meldung, die Du oben für den XP angibst, gibt FAH immer aus. Darunter steht das wesentliche, nämlich:

Code: Alles auswählen

[08:29:01] Folding@Home Client Core Version 1.25 (August 19, 2002)
[08:29:01] 
[08:29:01] Proj: work/wudata_01
[08:29:01] No information on assembly optimizations.
[08:29:01] Files status OK
[08:29:01] Writing local files: 
[08:29:01] Assembly optimizations on if available.

Diese Angaben sollten sie auch noch präzisieren. Ist aber auch schon auf der Mängelliste.

Michael.

[Euler]

Die Meldung, die Du oben für den XP angibst, gibt FAH immer aus. Darunter steht das wesentliche, nämlich:

Ich hab das gesehen, als die WU zum zweiten mal gestartet wurde.

Wie auch immer, diese Meldung können/sollten sie sich sparen,
da sie sehr verwirrend ist.

Ich habe aber am timing gemerkt, das GROMACS recht flott zur Sache geht.
Er schafft auf meinem 1900er 1% EL NOVO in ca. 6 min.

D.h. die komplette WU rechnet bei mir, Deine Theorie der konstanten Framezeiten
mal vorausgesetzt , ca. 10 h.
Nicht schlecht oder?
Ich leite daraus mal ab, daß SSE läuft.

Euler

[Michael H.W. Weber]

Mein Donnervogel braucht etwas mehr als das dreifache pro "frame" für die gleiche WU. Da sich dies nicht alleine durch die bei Deiner Kiste höhere Taktfrequenz erklären läßt und der TBird KEIN SSE besitzt, steht für mich nun klar fest, daß GROMACS sauber zwischen TBird und Palomino "cores" differenzieren kann und respektive 3DNow! bzw. SSE einsetzt.

Michael.

[Michael H.W. Weber]

Ich habe noch ein Problem mit fahMon (unter TINKER) entdeckt. Man kann aus dem GUI Client heraus aufs Netz zugreifen. Das schreibt FAH dann ins log hinein, wie unten gezeigt. fahMon meldet darauhin instantan, daß nicht genügend Daten vorliegen, was ja einzusehen ist, da es sich strikt am log orientiert und diese "Unterbrechungsmeldung" nicht berücksichtigt wurde.

Code: Alles auswählen

[13:43:10] PROJECT="work/wudata_01", NSTEPS=500000, DT=2.0000, DTDUMP=10.000000, TEMP=278.00
[13:43:11] TINKER: Software Tools for Molecular Design
[13:43:11] Version 3.8  October 2000
[13:43:11] Copyright (c)  Jay William Ponder 1990-2000
[13:43:11] portions Copyright (c)  Michael Shirts 2001
[13:43:11] portions Copyright (c)  Vijay S Pande 2001
[14:00:48] Finished a frame (1)
[14:20:00] Finished a frame (2)
[14:37:32] Finished a frame (3)
Opening "C:\PROGRA~1\INTERN~1\iexplore.exe" -nohome http://folding.stanford.edu/cgi-bin/userpage?q=Michael H.W. Weber http://folding.stanford.edu/cgi-bin/userpage?q=Michael H.W. Weber

Vielleicht könnte man - um auch in Zukunft sowas zu umgehen - das log derartig auswerten, daß man alle Zeilen, die nach einem "time stamp" nicht "Finished a frame" enthalten, ignoriert. Dann müßtest Du auch nicht warten, bis geklärt ist, ob unter GROMACS die "writing files" Zeile bleibt oder verschwindet (hab's übrigens schon vorgeschlagen).

Michael.

[Bommer]

Hallo

Ich habe heute früh um 8:30 Uhr auch mal wieder ein Gromacs Teil erhalten. Bei mir braucht es für einen Prozent mit AMD 1200 Mhz immer noch laut EM III ca. 14.15 Minuten.

Was mir nur aufgefallen ist, dass da solche "Fehler" auftreten.

[08:38:21] Completed 108000 out of 1200000 steps (9%)

+ Attempting to send results
- Connecting to server (171.64.122.119:8080)
+ Network send failure
- Error: Could not transmit unit 01. Keeping unit in queue.
[08:52:27] Writing local files
[08:52:27] Completed 120000 out of 1200000 steps (10%)


Ich hab DSL-Flatrate. Was ist das für ein Fehler. Später wie hier zu sehen nochmal.

[14:38:21] Completed 396000 out of 1200000 steps (33%)

+ Attempting to send results
- Connecting to server (171.64.122.119:8080)
+ Network send failure
- Error: Could not transmit unit 01. Keeping unit in queue.
[14:53:08] Writing local files
[14:53:08] Completed 408000 out of 1200000 steps (34%)


Woran kann das liegen. Weiss das jemand. Ist das nachvollziehbar ???

Cu Bommer

[Euler]

Vielleicht könnte man - um auch in Zukunft sowas zu umgehen - das log derartig auswerten, daß man alle Zeilen, die nach einem "time stamp" nicht "Finished a frame" enthalten, ignoriert. Dann müßtest Du auch nicht warten, bis geklärt ist, ob unter GROMACS die "writing files" Zeile bleibt oder verschwindet (hab's übrigens schon vorgeschlagen).

Michael.

Genau das tut er.
Wenn jedoch solche "noise" Zeilen dazwischen geschrieben werden,
verliert er die Synchronisation. D.h. er kann dann nicht mehr eindeutig
entscheiden, ob zusammenhängende timestamp-blocks zur gleichen
WU gehören.
Eine Heuristik, die das (korrekt) entscheidet wäre ziemlich aufwendig.
Es wäre unproblematisch, wenn jede WU ein eigenes logfile hätte.
Das das logfile jedoch über mehrere WUs jetzt unter Client 3.11 erhalten wird, sogar wenn der Client neu gestartet wurde, wird in Stanford als Fortschritt ("It's no bug it's a feature ..." ) betrachtet.

Man würde es den "Monitor-Bauern" auch leichter machen, wenn das logfile Format konsistent wäre.

D.h. Deine Trigger-Phrase "finished a frame" funktioniert wohl unter TINKER, nicht jedoch unter GROMACS.

Hier ist (leider) eine Fallunterscheidung nötig.

Ich mag gar nicht daran denken, was passiert, wenn noch GAH WUs dazwischen geraten ...

Die Sache kann dann leicht komplex werden und eine unifizierte Lösung für alle WU-Typen scheitern lassen.

Normalerweise werden Schnittstellen zwischen den Programmierern verschieder Teams abgesprochen, damit sowas nicht passieren kann.
Das ist hier natürlich nicht möglich, da sich offenbar noch nichtmal die verschieden Leute in Stanford (genügend) miteinander unterhalten.

Euler

[Euler]

NACHTRAG:

Natürlich lässt sich die Stabilität des Verfahrens steigern, wenn man
ein aggresiveres Filtern durchführt.
D.h. Nur noch relevante Zeilen mit Timestamp zulässt.

(a)
Im Falle von TINKER: "finished a frame"
Im Falle von GROMACS: "Completed xxx out of yyy steps ..."

UND

(b)
Streng die Monotonie der Frame # beachtet.

fahMon tut das im Moment nicht, was dazu führt, daß er für die Dauer eines Frames die Synchronisation verliert.
Nicht schön, aber auch kein Drama.

Im Rahmen des Updates werde ich das aber sicher überdenken/überarbeiten.

Diese Art von "irregulären" Meldungen sind a priori sehr schwer, wenn nicht unmöglich, abzuschätzen. Die Probleme ergeben sich immer erst im praktischen Betrieb, weswegen ich fahMon immer noch als beta betrachte.

Euler

[Michael H.W. Weber]

+ Attempting to send results
- Connecting to server (171.64.122.119:8080)
+ Network send failure
- Error: Could not transmit unit 01. Keeping unit in queue.

Das passiert genau dann, wenn der Stanforder Server mal wieder wegen Überlastung ausgefallen ist. An Deinem Ende ist also alles okay. Normalerweise stört das nicht, da - wie der Klient ja auch ankündigt - das Ergbnis in einer Warteschlange aufbewahrt und zu einem späteren Zeitpunkt geschickt wird. Ärgerlich ist es schon, aber wenn man mal die Zahl der FAH-Teilnehmer ansieht und mit der popeligen Zahl der verfügbaren Server vergleicht, geht einem schnell ein Licht auf, wo die Projektleiter schleunigst Geld zu investieren hätten. Angeblich ist das auch schon geschehen - allerdings wird noch immer auf die Serverlieferung gewartet.
Immerhin haben wir jetzt folgendes erreihen können: http://folding.stanford.edu/serverstat.html

Das ist eine Übersicht über den jeweiligen FAH Serverstatus. Ist ganz neu - mal sehen, ob es was taugt...

Es wäre unproblematisch, wenn jede WU ein eigenes logfile hätte.

Ja, aber das ist doch der Fall. Du hast ja nicht nur das "FAHlog.txt" im FAH Homeverzeichnis - wo alles zusammengeschrieben wird - sondern für jede bearbeitete WU auch noch ein separates log im WORK-Unterverzeichnis. Die nenen sich "logfile_01.txt"... Sind allerdings mit dem üblichen Zeilenumbruchproblem versehen, das auftritt wenn man unter Linux generierte ASCII-Dateien im Windoof NotePad öffnen will. Aber egal - typisch Microschrott...

Michael.

[Euler]

Es wäre unproblematisch, wenn jede WU ein eigenes logfile hätte.

Ja, aber das ist doch der Fall. Du hast ja nicht nur das "FAHlog.txt" im FAH Homeverzeichnis - wo alles zusammengeschrieben wird - sondern für jede bearbeitete WU auch noch ein separates log im WORK-Unterverzeichnis. Die nenen sich "logfile_01.txt"...

Har har, gut gebrüllt Löwe !

Nur das die keine Timestamps haben.
Und gerade darauf kommt's beim Monitor ja an...
Ausserdem ist es nicht so leicht möglich sie der aktuellen WU zuzuordnen,
da sich eine ganze Menge logfile_*.txt im work Verzeichnis tummeln können.
Man müßte also erst noch die Queue inspizieren, welches die aktuelle WU ist.

Sind allerdings mit dem üblichen Zeilenumbruchproblem versehen, das auftritt wenn man unter Linux generierte ASCII-Dateien im Windoof NotePad öffnen will. Aber egal - typisch Microschrott...

Michael.

Nun, das ist in Wirklichkeit kein Problem, wenn man darauf vorbereitet ist
und die Datei binär liest, sie jedoch als Text interpretiert.
Dann kann man sie "normalisieren", d.h. die CRs (ASCII Code 13 dec.) rausfiltern.

Übrigens solltest Du von Notepad Abstand nehmen.
Wenn schon Standard Windoof, dann nimm Wordpad, das kann damit umgehen.

Ich empfehle jedoch, sich SciTE zu besorgen.



Euler

[Michael H.W. Weber]

Har har, gut gebrüllt Löwe !

Joh!

Nur das die keine Timestamps haben.
Und gerade darauf kommt's beim Monitor ja an...

Stimmt.

Ausserdem ist es nicht so leicht möglich sie der aktuellen WU zuzuordnen,
da sich eine ganze Menge logfile_*.txt im work Verzeichnis tummeln können.
Man müßte also erst noch die Queue inspizieren, welches die aktuelle WU ist.

Entweder die "queue.dat" inspizieren oder anderweitig Datum/Zeit der lokalen log-Erstellung abchecken.

Übrigens solltest Du von Notepad Abstand nehmen.
Wenn schon Standard Windoof, dann nimm Wordpad, das kann damit umgehen.

Ich nutze sonst immer edit in der Konsole.

[Euler]

Das passiert genau dann, wenn der Stanforder Server mal wieder wegen Überlastung ausgefallen ist.
<snipped>
Ärgerlich ist es schon, aber wenn man mal die Zahl der FAH-Teilnehmer ansieht und mit der popeligen Zahl der verfügbaren Server vergleicht, geht einem schnell ein Licht auf, wo die Projektleiter schleunigst Geld zu investieren hätten. Angeblich ist das auch schon geschehen - allerdings wird noch immer auf die Serverlieferung gewartet.

Prinzipiell ist das natürlich richtig.
In diesem speziellen Fall liegt der Fall aber wohl anders, da alle
AS Server riesige IdleTimes (> 12 Stunden) aufwiesen.
Da scheint irgendwas mit dem internen Netzwerk in Stanford nicht zu stimmen. Über Nacht, wenn niemand da ist, blockieren dann alle Server auf einmal, was absolut ätzend ist. Man kann das bei statsman schön an einer tiefen "Kerbe" sehen.

Immerhin haben wir jetzt folgendes erreihen können: http://folding.stanford.edu/serverstat.html

Das ist eine Übersicht über den jeweiligen FAH Serverstatus. Ist ganz neu - mal sehen, ob es was taugt...

Michael.

Ja, das taugt was.
Die obigen Schlüsse kannst Du aus dieser Page ableiten.

Euler