tuxthekiller said:
Hat einer ne Idee wieso die WUs mit Linux immer so lange dauern? Ist das bei anderen Projekten auch so?
TS hat das mit dem optimierten Client so toll beschrieben, er hat doch bestimmt auch eine Erklärung, warum die WUs unter Linux so lange brauchen 😀
Hi Tux,
danke für die Schmeichelei… 😉
Die Frage ist für mich, ob es wirklich länger dauert, die WUs zu berechnen. Das einzige, was ich weiss ist dass die claimed Credits unter Linux erheblich niedriger sind. Das kann aber wie schonmal beschrieben unterschiedliche Ursachen haben (Benchmarks und/oder Dauer).
Um ‘rauszubekommen, ob BOINC unter Linux wirklich “langsamer” ist (also die WUs zeitlich gesehen länger brauchen) sollte mal jemand den folgenden Test machen (ich scheide da leider aus Zeitgründen aus :roll:):
Mit derselben Maschine einmal unter Windows und unter Linux WUs berechnen und posten, wieviele Sekunden CPU-Zeit die WU tatsächlich benötigt hat. Also kommen zwei Sekunden-Anzahlen heraus.
Weiterhin sind interessant:
BOINC-Benchmark Werte von unoptimiertem UND optimiertem Client unter Windows UND Linux. Also insgesamt 4 Benchmark-Ergebnisse!
Wenn du da ein wenig Zeit investierst, helf ich gerne bei der Analyse und Problembehebung (sofern möglich).
tuxthekiller said:
Bei der “Computer Summary” von meinem Linux Router steht “Result duration correction factor” – 0.562748. Könnte das was damit zu tun haben?
Auf dem wirklich guten BOINC-Wiki (http://boinc-wiki.ath.cx/) ist der Factor hier beschrieben:
http://boinc-wiki.ath.cx/index.php?title=Result_Duration_Correction_Factor
Um es kurz zusammenzufassen:
Der “Result duration correction factor” beschreibt, wie genau die Vorhersage der Zeit pro WU ist. Bei einem Wert von 1.0 wird eine WU genau so schnell berechnet, wie vorhergesagt.
Anmerkung: Die Vorhersage wird aufgrund des Benchmark-Werts berechnet! Wie schon im Thread zum optimierten Client gesagt, ändern sich die Benchmark-Werte mit einem optimierten Client.
Außerdem sind die vom Client geclaimeten Credits vom Benchmark abhängig. Ist nun der “Result duration correction factor” gleich 1.0 fordert dieser Client eine absolut faire Anzahl an credits an!
Ist er kleiner als 1.0, fordert er zu wenige Credits an (es wäre fairer, mehr zu claimen).
Ist er größer als 1.0, fordert er zu viele Credits an (es wäre fairer, weniger zu claimen).
Das passt gewissermaßen dazu, dass der Linux-Client zu wenig claimed und nicht wirklich langsamer rechnet.
Vergleichswerte: Meine Windows-Systeme (optimierte Clients) laufen mit “Result duration correction factor”-Werten von 0.9 bis 1.4.
CU,
TS