Folding@home - Zweck des "benchmarking"

[Michael H.W. Weber]

Ich habe mir mal die Mühe gemacht, zu überprüfen, inwieweit die "benchmarking"-Funktion des FAH-Clients sinnvoll arbeitet.
Man muß dazu wissen, daß es bei FAH - wie bei anderen Projekten ja auch (z.B. SOB) - Abgabefristen für jede WU gibt - dies ist essentiell für den schnellen Abschluß laufender FAH-Einzelprojekte. Die Abgabefristen sind üblicherweise normiert auf einen Intel Celeron @500 MHz. Besitzt man ein schnelleres System, kann der Server die WU früher erwarten. Er sollte dies auch tun und entsprechend die Abgabefrist verkürzen, um ein schneller Vorankommen des Projekts zu gewährleisten (neu ausgegebene WUs hängen von vorhergehend berechneten ab!). Dazu haben die FAH-Entwickler sich etwas ausgedacht: Sie bestimmen die Geschwindigkeit des jeweiligen Systems, wenn FAH erstmals installiert wird. Allerdings ist das schlichte Auslesen der CPU-Frequenz kein gutes Mittel hierzu, da oft andere Programme CPU-Performance verbrauchen, d.h. im Endeffekt nicht die volle "power" für FAH zu Verfügung stehen kann. Deshalb wird im Verlauf der Clientkonfiguration ein "benchmark"-Test durchgeführt, der dem Server meldet, wieviel "power" das jeweilige System zum Benchmarkzeitpunkt bereitstellt. Der ermittelte Wert wird dann mit einigen Umrechnungsfaktoren so ausgewertet, daß genügend Zeit zum Abschluß der WU zur Verfügung steht.

FAH führt diesen Benchmarktest bei der Installation des Clients durch - interessanter Weise ergaben meine Untersuchungen, daß offenbar die Gesamtperformance zur Fertigstellung einer WU eine Korrektur der Beurteilung des Systems auslösen kann. Dies war mir neu und kann man folgendem "log" entnehmen:

Code: Alles auswählen

[08:23:50] Completed 500000 out of 500000 steps  (100)
[08:23:52] Writing final coordinates.
[08:23:53] Past main M.D. loop
[08:24:52] 
[08:24:52] Finished Work Unit:
[08:24:52] - Reading up to 1029552 from "work/wudata_02.arc": Read 1029552
[08:24:53] - Reading up to 0 from "work/wudata_02.xtc": Read 0
[08:24:53] goefile size: 0
[08:24:53] logfile size: 49075
[08:24:53] Leaving Run
[08:24:57] - Writing 1086711 bytes of core data to disk...
[08:24:57]   ... Done.
[08:24:57] - Shutting down core
[08:24:57] 
[08:24:57] Folding@home Core Shutdown: FINISHED_UNIT
[08:25:01] CoreStatus = 64 (100)
[08:25:01] Sending work to server
[08:25:01] Unit 2 finished with 39 percent of time to deadline remaining.
[08:25:01] Updated performance fraction: 0.386550

[08:25:01] + Attempting to send results
[08:25:01] - Reading file work/wuresults_02.dat from core
[08:25:01]   (Read 1086711 bytes from disk)
[08:25:01] Connecting to http://171.67.89.150:8080/
[08:25:06] Initial: 0000 + Results successfully sent
[08:25:06] Thank you for your contribution to Folding@home.

Wie man sieht, meldet der Client bei Abschluß einer WU genau, wieviel Prozent der Abgabefrist noch verbleiben:

Code: Alles auswählen

[08:25:01] Unit 2 finished with 39 percent of time to deadline remaining.

Ich habe den Client immer nur im Hintergrund laufen lassen und mit SOB (welches mit höherer Priorität läuft) die Leistung des FAH-Clients über Tage hinweg nach unten gedrückt. Interessanter Weise modifiziert der FAH-Client daraufhin die gespeicherte Benchmarkperformance:

Code: Alles auswählen

[08:25:01] Updated performance fraction: 0.386550

Es sieht demnach so aus, als wenn vom Client festgestellt wird, daß nur knapp 40% der ursprünglich über den Benchmarktest ermittelten Leistung effektiv zur Verfügung stehen. Daraufhin dürften die Abgabefristen entsprechend angepasst (in diesem Fall verlängert) werden. Nicht schlecht, Herr Specht.

Michael.