[ANN] F@H Console Monitor

[Euler]

Howdy folks,

ich habe einen einfachen (aber funktionierenden) Console Monitor für
F@H, der Cross-Platform läuft fertiggestellt, da mich das Monitor Problem echt genervt hat.

Einzige Bedingung: Python (Version >= 2.1)
Unter Windows ist sicher ActiveState Version 2.2.x das Richtige, unter
allem was *X heisst, ist Python (meistens) obligatorisch.

Ich hab das Ding jetzt seit ca. einer Woche auf verschiedenen Systemen
kreuz und quer laufen. Soll heißen, läuft auf Windows und monitored WUs auf Win & *X oder läuft auf *X und monitored WUs auf *X und/oder Win.
Alles schön im Netz gemixt.

Sollte Interesse bestehen, lasst's mich wissen.
Entweder stelle ich selber ne FTP location parat, oder lade es irgendwohin, wo Ihr es Euch holen könnt.

Wenn jemand möchte, kann er/sie ein GUI dazu basteln. Die nötigen
Hooks sind vorhanden und können ggf. über pipes oder sockets zur Verfügung gestellt werden.

Gruss
Euler

[Euler]

Ach ja, so sieht das ganze dann aus.
Kann man unter Windoze beispielsweise in einer DOS-Box laufen lassen...

Code: Alles auswählen

Protein: "PolyQ50", frame 56/100, running on "Euler#1"
Last frame time        =    281 seconds [00:04:41]
Avg-time/frame         =    279 seconds [00:04:39]
Current frame time     =    273 seconds [00:04:33],  97 % completed
Estimated elapsed time =  15453 seconds [04:17:33]
Projected WU finish: Thu 2002-06-27 09:26:35, countdown: [03:26:12]
===============================================================================
Protein: "proteinAg29a", frame 13/100, running on "Goedel"
Last frame time        =   4875 seconds [01:21:15]
Avg-time/frame         =   4902 seconds [01:21:42]
Current frame time     =    821 seconds [00:13:41],  16 % completed
Estimated elapsed time =  59549 seconds [16:32:29]
Projected WU finish: Tue 2002-07-02 04:56:42, countdown: [4 days 22:56:19]
===============================================================================
Protein: "PolyQ50", frame 60/100, running on "Euler#2"
Last frame time        =    243 seconds [00:04:03]
Avg-time/frame         =    241 seconds [00:04:01]
Current frame time     =    235 seconds [00:03:55],  96 % completed
Estimated elapsed time =  14572 seconds [04:02:52]
Projected WU finish: Thu 2002-06-27 08:42:31, countdown: [02:42:08]
===============================================================================

Euler

[Michael H.W. Weber]

Bin interessiert an dem Progrämmchen. Wo nehme ich Python für Windoof her?

Michael.

[Euler]

Bin interessiert an dem Progrämmchen. Wo nehme ich Python für Windoof her?

Michael.

http://www.activestate.com/Products/ActivePython/

Nimm aber ne Version >= 2.2.*

Soll ich Dir vorab mal ne Instanz mailen, bevor ich was FTP-artiges
fertig habe? Dann lass mir mal Deine Adresse im Postfach.

Euler

[Euler]

Es ist mir gelungen, eine Windows Version zu erstellen, die kein Python benötigt.

Alles schön als selbstinstallierendes .exe verpackt.

ftp://blank-it.dyndns.org/pub/FAH/FAHMo ... onitor.exe

Die Unix Version (braucht Python) ist hier:
ftp://blank-it.dyndns.org/pub/FAH/FAHMo ... tor.tar.gz

Michael, es wäre schön, wenn Du die files spiegeln könntest, da ich die o.g. URLs nur als provisorisch ansehe.

Euler

[Michael H.W. Weber]

Ich werde Deinen Monitor gleich mal anwerfen. Ich kann ihn dann gerne auch auf www.folding.de.tf zum Download anbieten.

Michael.

[Michael H.W. Weber]

Ok. Die Installation lief auf Anhieb gut, bis auf die Unschönheit, daß das DOS-Installationsfenster offen blieb. Das sollte noch geschlossen werden. Es wäre auch schön, wenn der Monitor entweder die Position des FAH-Clients selbst lokalisieren könnte ODER ganz schlicht nach ihr in einem kurzen Dialog während der Installation fragt. Das Editieren der "config"-Datei ist etwas lästig für die typischen Windoof-Benutzer.

Habe dann auch die letzte Version von FAH kurz vor dem Monitortest noch installiert (FAH 3.1).
Probleme sind folgende: Erstens ist der Monitor nicht so akkurat wie EM3 - er kann jedenfalls nicht nach dem ersten "frame" die korrekte Gesamtdauer angeben - die liegt um Stunden falsch. Mit zunehmender "frame"-Berechnung wird er allerdings immer akkurater. Dies erinnert mich eigentlich ein wenig an FoldMonitor, der ja auch "annähert". Mir wäre eine Angabe wie bei EM3 eigentlich lieber (die basiert bei EM3 schlicht auf der Auswertung der "time stamps" im "fahlog" - glaube ich). Desweiteren läßt sich der Monitor nicht so einfach schließen. CTRL+C funktioniert gar nicht und beim Schließen des Konsolenfensters kriegt man erst mal die typische Windoof-DOS-Fensterschließwarnmeldung (klasse Wort, wa? ).
Also wenn Du nichts dagegen hast, würde ich vorschlagen, wir optimieren Deinen Monitor jetzt häppchenweise ein wenig - verpassen ihm auch eine GUI - und benutzen ihn als Rechenkraft/Germany FAH-Standardmonitor. Gut finde ich, daß es gleich auch eine Version für Linux gibt!

Daten, die der Monitor noch für jede Instanz anzeigen sollte sind:

- User name: Michael H.W. Weber (Team 3)
- User ID = 6773493907453ADF
- Machine ID #1

...zu entnehmen aus "client.cfg", und:

[10:58:19] " 391 GAAA_tetraloop (also Projektnummer und Atomzahl, WU-Namen hast Du ja schon drin)
[10:58:19] - Run: 18 (Clone 38, Gen 19)
[10:58:19] - Dynamic steps required: 500000

...zu entnehmen aus "fahlog.txt". Außerdem wäre es noch cool, wenn der Monitor noch FAH-Version (also Version von fah3console.exe - jetzt 3.1) und die "core"-Version angeben würde. Weitere Funktionsvorschläge:

-Bugreport (Textfile, der alle Infos enthält, die für Stanford wichtig wären - kann man direkt in deren Forum posten)
-löschen von WUs aus dem Monitor heraus (GROMACS- oder GAH-WU-Streß beenden)
-Option/Checkbox um FAH nach Abschluß & senden der aktuellen WU zu beenden
-optionales, akustisches Signal, sobald WU fertig ist (sowie falls Fehler auftritt)
-"credits" im Monitor anzeigen
-Browser aus dem Monitor "launchen" mit rechenkraft.net / folding.de.tf / Stanford/stats-Seiten
[-"skin features" analog zu FoldMonitor]
-"frame & WU counting"
-Aufruf der fahlogs aus dem Client heraus
-Ansicht des Proteins (über SPDBV, Chime, Cn3D oder ähnliches)
-anlegen eines Benchmarkfiles, wo die "frame"-Zeiten aller je erhaltenen WUs gespeichert werden (also die schnellsten - ein Eintrag pro Projektnummer) - erlaubt doch ganz gut einen FAH-Systemperformancevergleich

Ich würde gerne zur GUI was beitragen. Fragt sich, wie ich das machen muß. Einzelne Schaltelemente als separate Grafiken erstellen? Oder wie funktioniert dies. Wie groß sollen die Dimensionen der Oberfläche sein? Fragen und Vorschläge... hat ja alles keine Eile...

Michael.

[Euler]

Michael,

Ok. Die Installation lief auf Anhieb gut, bis auf die Unschönheit, daß das DOS-Installationsfenster offen blieb.

Schluchz, Du hast hier mein vollstes Mitgefühl.
Da Du das Ding aber wahrscheinlich nicht jeden Tag neu installierst, kommst Du sicher bald über dieses
schlimme Erlebnis hinweg.

Das sollte noch geschlossen werden.

One click on the close button does the trick.

Lässt sich leider nicht automatisieren, da der Self-Extracting-Installer ein DOS-Batchfile aufruft.
(Welches Notepad mit dem README launched)
Kann ich weglassen, war als zusätzlicher Service gedacht.
Dann muss Deinerseiner Notepad mit der Hand aufmachen, an sich auch sehr unschön ...

Es wäre auch schön, wenn der Monitor entweder die Position des FAH-Clients selbst lokalisieren könnte

Das ist eine sehr heikle Sache.

1.) Obwohl technisch einfach, kann es leicht passieren, daß ein User ne 120 GB Platte hat und zusatzlich 18 Netzlaufwerke
gemappt hat. Ganz zu schweigen von vielleicht noch 8 Samba Servern im heterogenen Firmennetz.
Wie lange soll die Suche dann dauern?

Ich weiß - das trifft auf Dich nicht zu - kann aber passieren.

Bei mir in der Firma beispielsweise, sind mehr als 18 Rechner vernetzt, die alle mehr oder weniger Festplatten mit einer
Gesamtgröße von ~ 1 TB teilen.

2.) Es soll Leute geben, die eine ganze Menge von "Shadow" FAH Subtrees haben. (Warum auch immer )
Wie soll das Programm "erraten", welches Verzeichnis gerade aktiv ist?

Ich würde mich an sich nicht gerne auf diese Sache einlassen, wäre jedoch verhandlungsbereit, einen Optionsswitch
einzubauen, sollten es außer Dir noch mehr Leute dringend wünschen.

ODER ganz schlicht nach ihr in einem kurzen Dialog während der Installation fragt. Das Editieren der "config"-Datei ist etwas lästig für die typischen Windoof-Benutzer.

Yeah, etwas lästig !
Dies ist ein Text-Console-Monitor.
Wie kommst Du auf die Idee, daß der Dialoge (ein typisches GUI Control-Aggregat) haben könnte ??

Ich denke, daß der typische User, der DC betreibt, nicht zu dumm ist ein einfaches Textfile zu editieren.
(Zumal wenn er akademisch gebildet ist)

Aber, sollte jemand ein GUI basteln, ist das sicher eine Option für seine To-Do-List.

Habe dann auch die letzte Version von FAH kurz vor dem Monitortest noch installiert (FAH 3.1).
Probleme sind folgende: Erstens ist der Monitor nicht so akkurat wie EM3

Wie akkurat EM3 oder xyz ist, kann ich nicht beurteilen.

- er kann jedenfalls nicht nach dem ersten "frame" die korrekte Gesamtdauer angeben -

Er kann das genau so korrekt, wie das nach nur einem Frame möglich ist.

die liegt um Stunden falsch.

No.
Hier übertreibst Du.
Er ist so genau, wie das eben mathematische "Vorhersage"-Verfahren erlauben.
Genau genommen verstoßen solche "Vorhersagen" gegen naturwissenschaftliche Gesetze und bewiesene Sätze der
modernen Mathematik.
Man kann eben nicht in die Zukunft schauen.

Nimm folgenden simplen Fall:
Ein Monitor sagt Dir eine Zeit X in der Zukunft voraus.
Eine Speicherzelle Deines RAMs wird von einem hochenergetischen Quantum getroffen und Du mußt den Rechner neu booten.
Logischerweise war die Vorhersage X ganz einfach falsch.
(Für theoretisch interessierte -> Berechenbarkeit /Halteproblem der Turingmaschine)

Ich habe mir große Mühe beim Design der Hochrechnungen für das WU-Ende gegeben.
Beispielsweise benutzt das Programm gleitende Durchschnitte (floating averages), die wesentlich weniger empfindlich für
Vorgänge in der Vergangenheit sind als ein normales arithmetisches Mittel.
Weiterhin schaltet er automatisch zwischen verschiedenen Vorhersage-Strategien um.

Beispiel:
Ein Frame rechnet im Schnitt X Sekunden.
Nun rechnet ein anderes Programm mit höherer Priorität als FAH über eine gewisse Dauer hinweg.
Die Zeit X' für den laufenden Frame ändert sich erheblich, und kann gut und gerne
doppelt so groß wie X sein.
Mein Programm versucht das abzufangen, indem es nun mit der laufenden Frame-Time weiterrechnet, bis sie wieder
im durchschnittlichen Bereich liegt.

Ich habe in den jetzt wochenlangen Tests keinerlei solche eklatanten Falschvorhersagen beobachtet, wie Du sie beschreibst.

Ich hoffe Deine Hardwareuhr geht nicht "nach dem Mond" !!!

Besonders im Netz, wenn der Monitor WUs auf verschiedenen Rechnern beobachtet, ist es extrem wichtig, daß
die Hardwareuhren dieser Rechner synchron sind.
(-> Time synchronizing daemons -> Für Windows beispielsweise "Tardis")

Mit zunehmender "frame"-Berechnung wird er allerdings immer akkurater.
Dies erinnert mich eigentlich ein wenig an FoldMonitor, der ja auch "annähert".
Mir wäre eine Angabe wie bei EM3 eigentlich lieber (die basiert bei EM3 schlicht auf der Auswertung der "time stamps" im "fahlog" - glaube ich).

Dann musst Du mir erklären, wie EM3 in die Zukunft schaut.
Meine Berechnungen beruhen übrigens schlicht auf der Auswertung der "time stamps" im "fahlog".
Trotzdem Danke für den Tip...

Desweiteren läßt sich der Monitor nicht so einfach schließen. CTRL+C funktioniert gar nicht und beim

CTRL+C funktioniert.
Da der Monitor jedoch für n (standard 60) Sekunden in einem "Sleep-Zustand" ist, und Windoze keine Signals kennt,
kann es bis zu n Sekunden dauern, bis Dein CTRL+C dort ankommt, wo es hin soll.
Auf einem "richtigem" Betriebssystem - Du weißt schon, die mit dem X - geht das sofort.

Schließen des Konsolenfensters kriegt man erst mal die typische Windoof-DOS-Fensterschließwarnmeldung (klasse Wort, wa? ).

Besschwerden zum Handling/Look & Feel von Windoze nimmt

Microsoft Corporation
One Microsoft Way
Redmond, WA
U.S.A.

entgegen.

[Und entsorgt sie dann in "Ablage rund" ]

Also wenn Du nichts dagegen hast, würde ich vorschlagen, wir optimieren Deinen Monitor jetzt häppchenweise ein wenig - verpassen ihm auch eine GUI - und benutzen ihn als Rechenkraft/Germany FAH-Standardmonitor. Gut finde ich, daß es gleich auch eine Version für Linux gibt!

Für konstruktive und vernünftige Vorschläge zur Optimierung bin ich immer dankbar.

Daten, die der Monitor noch für jede Instanz anzeigen sollte sind:

- User name: Michael H.W. Weber (Team 3)
- User ID = 6773493907453ADF
- Machine ID #1

...zu entnehmen aus "client.cfg", und:

[10:58:19] " 391 GAAA_tetraloop (also Projektnummer und Atomzahl, WU-Namen hast Du ja schon drin)
[10:58:19] - Run: 18 (Clone 38, Gen 19)
[10:58:19] - Dynamic steps required: 500000

...zu entnehmen aus "fahlog.txt". Außerdem wäre es noch cool, wenn der Monitor noch FAH-Version (also Version von fah3console.exe - jetzt 3.1) und die "core"-Version angeben würde. Weitere Funktionsvorschläge:

Also, ich habe mich redlich bemüht möglichst wenig und nur relevante Information auszugeben.
Grund: Hat man mehr als 1 oder 2 Clients laufen, wird schlicht das Fenster zu klein.

Ich sehe aber ein, daß man einen Switch einführen könnte, der optional Zusatzinformationen anzeigt, wenn
der User das wünscht.
(Ob das Fenster dann zu klein wird, ist sein Problem.)

-Bugreport (Textfile, der alle Infos enthält, die für Stanford wichtig wären - kann man direkt in deren Forum posten)
-löschen von WUs aus dem Monitor heraus (GROMACS- oder GAH-WU-Streß beenden)
-Option/Checkbox um FAH nach Abschluß & senden der aktuellen WU zu beenden
-optionales, akustisches Signal, sobald WU fertig ist (sowie falls Fehler auftritt)
-"credits" im Monitor anzeigen

Wow...
Ich weiß nicht, ob das nicht über die typischen Aufgaben eines Monitors hinausgeht.
(Tut's zumindest mit meinem Verständnis für einen "Monitor", der ja ein "Beobachter" ist.)
Ich glaube, hier sollte man mal über ein "multi-purpose AddOn" nachdenken.
Ich würde diese Optionen nicht in meinen Monitor einbauen.

-Browser aus dem Monitor "launchen" mit rechenkraft.net / folding.de.tf / Stanford/stats-Seiten
[-"skin features" analog zu FoldMonitor]
-"frame & WU counting"
-Aufruf der fahlogs aus dem Client heraus
-Ansicht des Proteins (über SPDBV, Chime, Cn3D oder ähnliches)
-anlegen eines Benchmarkfiles, wo die "frame"-Zeiten aller je erhaltenen WUs gespeichert werden (also die schnellsten - ein Eintrag pro Projektnummer) - erlaubt doch ganz gut einen FAH-Systemperformancevergleich

Ich würde gerne zur GUI was beitragen. Fragt sich, wie ich das machen muß. Einzelne Schaltelemente als separate Grafiken erstellen? Oder wie funktioniert dies. Wie groß sollen die Dimensionen der Oberfläche sein? Fragen und Vorschläge... hat ja alles keine Eile...

Michael.

Generell: GUI und alles was dazu gehört, ist nicht meine Baustelle.
Sollte jemand eins bauen wollen, stehe ich ihm/ihr jederzeit zur Verfügung, was die Datenschnittstelle angeht.

Weiterhin: Der Monitor ist Free & OpenSource. Jeder der eigene Experimente basierend auf seiner CodeBase machen möchte,
darf das natürlich jederzeit uneingeschränkt tun.

Schlußsatz: Warten wir mal, was GROMACS bringt. Schätze wir können den jetzigen Ansatz dann sowieso verschrotten.


Grüsse
Euler

[S_Garbe]

@Euler - warum rufst Du die Batchdatei überhaupt auf? - das steht doch nur eine Zeile drin - die kannst Du auch gleich direkt aufrufen

Code: Alles auswählen

;The comment below contains SFX script commands

Path=Euler\FAHMonitor
Setup=notepad deltaTimestampRC
Setup=notepad readme.txt

Gruß
Stefan

[Euler]

@Euler - warum rufst Du die Batchdatei überhaupt auf? - das steht doch nur eine Zeile drin - die kannst Du auch gleich direkt aufrufen

Code: Alles auswählen

;The comment below contains SFX script commands

Path=Euler\FAHMonitor
Setup=notepad deltaTimestampRC
Setup=notepad readme.txt

Gruß
Stefan

Stefan,

das hat einen ganz einfachen Grund.
Das war das erste mal, das ich so einen WinRAR SFX benutzt habe.
Ich hab's einfach nicht gewusst.

Danke für den Tip, werd's gleich mal ändern.

[S_Garbe]

@Euler - ich hab es mir eben gerade auch das erste Mal angeschaut
- ich hab mir aber gedacht- wenn ich ne Batchdatei aufrufen kann, dann sollte eine EXE auch gehen - und hab es gleich mal mit Deiner Datei ausprobiert

Gruß
Stefan

[Euler]

Nachtrag:

1.) Unter Windows 2000 schließt sich das Fenster der Installations-DOS-Box automatisch, sobald man Notepad beendet.

2.) Hat man definitiv nur einen Client auf der Maschine laufen, so braucht man kein "deltaTimestampRC" profile (config).

Aufruf:

Code: Alles auswählen

FAHMon.exe -c "RoadRunner" -d "c:/path/to/FAH"

Der Parameter -c (CPU-Name) ist optional und wird standardmäßig auf den Rechnernamen gesetzt.

Die komplette Aufrufsyntax ist wie folgt:

Code: Alles auswählen

fahMon.exe [options]

Options:
        -c|--cpu=<Name>         CPU Name
        -d|--directory=<Name>   Directory, which contains FAHlog.txt
        -p|--profile=<Name>     Full path to alternative profile
        -r|--refresh=<Number>   # seconds for screen refresh, default=60

If no options are given, the default profile "deltaTimestampRC" is used.

Die neuen Installationen mit dem Fix von Stefan finden irgendwann heute im Laufe des Tages ihren Weg in den FTP Path.

Euler