Warum ein optimierter Client Quatsch ist! LESEN!
- Ersteller Olivier
- Erstellt am
Olivier
Grand Admiral Special
Hallo,
hier gibts eine kurze Übersicht zur jeweils aktuellen BOINC-Version und dem passenden optimierten Client, den viele von uns einsetzen.
aktuelle BOINC-Version: 5.8.15
Original Clients (unoptimiert): http://boinc.berkeley.edu/download.php
Zunächst muss der Original Client installiert werden und anschließend die Dateien vom optimierten Client in das Installationsverzeichnis kopiert werden.
---
Es folgen ein paar Infos zur Funktionsweise von optimierten BOINC-Clients.
Warum eine WU trotz optimiertem Client NICHT eine Sekunde schneller berechnet werden kann...
Grundsätzlich werden im täglichen BOINC-Betrieb unterschiedliche Arten von Executables (.EXE) ausgeführt. Das seht ihr auch jederzeit im Windows Task-Manager (wenn ihr Windows benutzt).
Die Sache ist ja die, dass die Executables zur WU-Berechnung z.B. vom Scripps-Institute (für Predictor) kommen, während der BOINC-Client von der Berkely-Uni bzw. von irgendjemand anders kommt, der ihn verändert und neu kompiliert hat.
Folgende EXEs werden normalerweise gestartet:
boinc.exe (vom Client)
boincmgr.exe (vom Client)
z.B. mfoldB125_4.28_windows_intelx86.exe (vom Predictor-Projekt)
Die ersten beiden werden vom Client mitgeliefert und die letzte wird vom Client erst selbst heruntergeladen. Das heisst, der Client fragt beim Projekt an und bekommt dann die URL zum Download der mfoldB125_4.28_windows_intelx86.exe. Somit lädt auch der optimierte Client dieselbe mfoldB125_4.28_windows_intelx86.exe herunter. Und genau diese ist es, die die ganze Arbeit erledigt.
Aus diesem Grund ist die WU-Berechnung mit einem optimiertem Client nicht schneller!
Was der optimierte Client überhaupt bewirkt...
Aufgrund erweiterter Befehlssätze (z.B. SSE, SSE2, SSE3) sind moderne Prozessoren in der Lage gewisse Dinge schneller bzw. effizienter zu berechnen. Diese besonderen Befehle müssen aber bei der Entwicklung eines Programms explizit benutzt werden um den Geschwindigkeitsvorteil auch nutzen zu können.
Nun gibt es wie oben beschrieben zwei Arten von Executables bei BOINC. Und beide führen Berechnungen durch. Zwar sehr unausgewogen, aber dennoch.
Der Client berechnet keine WUs. Aber er führt den CPU-Benchmark durch.
Nochmal: Der Benchmark ist Teil des Clients und hat mit der WU-Berechnung nicht die Bohne zu tun. Aufgrund der Benchmarkwerte wird z.B. auch eine hochgerechnete/geschätzte Zeit für die Berechnung einer WU im BOINC-Manager angezeigt.
Der einzige effektive Sinn und Zweck des Benchmarks ist aber die Berechnung eines claimed credits für jede WU. Das wird wieder vom Client gemacht. Der nimmt sich im Anschluss an die Berechnung einfach nur die verbrauchte CPU-Zeit vom Executable und setzt die zusammen mit den Benchmark-Ergebnissen in irgendeine Formel (mit weiteren Variablen) ein und schwupps kommt der claimed credit heraus...
Zweck der Optimierung ist nun folgender: Wenn die EXE vom Predictor z.B. SSE(2) unterstützen kann, der Benchmark aber nicht (und das kann er offensichtlich im Original-Zustand nicht), ist dein Rechner bei der WU-Berechnung schneller als vom Benchmark vorher vorhergesagt. Das wäre ja egal, wenn die claimed credits nicht davon abhingen. D.h. du bringst den Benchmark auf die Performance, die bei den WUs schon lange anliegt (der Benchmark hat vorher immer das System UNTERschätzt!).
Dass diese UNTERschätzung tatsächlich vorlag, erkennt man daran, dass die vorhergesagte Zeit pro WU exakter (und NICHT zu kurz!!) ist als vorher!
Ein anderer Fall wäre es, wenn die Predictor-EXE SSE(2) nicht benutzt. Dann würde der Benchmark die WU-Berechnung ÜBERschätzen. Das würde in einer zu kurzen Vorhersage für die WU-Berechnung resultieren. Damit würdest du quasi "cheaten"... (Predictor benutzt SSEx)
Damit hat die Optimierung nichts mit den WUs zu tun (da müsste eine Optimierte EXE vom Predictor kommen), sondern nur mit der credit-Berechnung...
Warum der granted credit trotz optimiertem Client nicht unbedingt höher sein muss...
Also nochmal folgende Zusammenfassung, die aufschlüsseln sollte was der optimierte Client maximal herausholen kann:
Der optimierte Client ändert wie oben beschrieben die claimed Credit-Werte die dein Rechner anfordert, wenn eine WU fertig berechnet ist.
Jede WU wird von mehreren Clients berechnet um die Ergebnisse zu vergleichen
Der claimed Credit eines jeden Rechners berechnet sich aus verbrauchter CPU-Zeit und dem Benchmark-Ergebnis des Clients
(da das Benchmark Ergebnis mit dem optimierten Client besser ausfällt, gibt es hier mehr Punkte)
Nach diesen Regeln wird aus den claimed Credits der gelieferten Resultate ein granted Credit für alle Berechner derselben WU berechnet.
Somit gilt folgendes:
War der Rechner schon immer ein Low-Performer (also niedriger claimed Credit: es wird fast immer der Credit anderer gegranted, z.B. claimed unter 6) kann es sein, dass sich der optimierte Client als Nachteil bemerkbar macht. Wenn man nämlich in das Mittelfeld rutscht und damit die Wahrscheinlichkeit erhöht, dass der eigene Credit gegranted wird, der zwar besser aber immernoch niedrig ist. Hier ist es vielleicht besser, sich darauf zu verlassen, denn Credit der anderen zu bekommen...
Für High-Performer (z.B. claimed Credits > 20) kann man den optimierten Client installieren. Er bringt aber vermutlich nicht so extrem viel, weil auch bisher kaum claimed Credit der jeweiligen Maschine wirklich gegranted wird. Man verringert eher die Wahrscheinlichkeit. Aber schaden wird es vermutlich nicht.
Für die Rechner im Mittelfeld (claimed Credit so um die 10) Macht das am meisten Sinn, würde ich sagen. Die Wahrscheinlichkeit ist recht hoch, dass man nicht schlechtester oder besser wird und daher den gegranteten Wert erhöht.
Mein 1,3GHz Tuleron ist da ein gutes Beispiel: für eine bprion-WU ist der claimed-Wert von ca. 14 auf ca. 16 gestiegen. Damit hängt er irgendwo zwischen Mittelfeld und High-Performer. Es wurde in der Vergangenheit bei etwa jeder 3.-4. WU von mir der claimed Credit gegranted. Bei ca. 15 WUs pro Tag und 1/3 eigener Quote kann man also ca. 10 Credits pro Tag mehr effektiv herausbekommen (5*14=70 vs. 5*16=80)...
Viel mehr ist nicht drin. Das ist also kein Wundermittel...
(Anmerkung von mir) Lest meinen unteren Tread dann werdet Ihr sehen das OPTICLIENTS niemanden etwas bringen... NICHT BEI SPINHENGE!
(Quelle: Meisterkuehler.de)
hier gibts eine kurze Übersicht zur jeweils aktuellen BOINC-Version und dem passenden optimierten Client, den viele von uns einsetzen.
aktuelle BOINC-Version: 5.8.15
Original Clients (unoptimiert): http://boinc.berkeley.edu/download.php
Zunächst muss der Original Client installiert werden und anschließend die Dateien vom optimierten Client in das Installationsverzeichnis kopiert werden.
---
Es folgen ein paar Infos zur Funktionsweise von optimierten BOINC-Clients.
Warum eine WU trotz optimiertem Client NICHT eine Sekunde schneller berechnet werden kann...
Grundsätzlich werden im täglichen BOINC-Betrieb unterschiedliche Arten von Executables (.EXE) ausgeführt. Das seht ihr auch jederzeit im Windows Task-Manager (wenn ihr Windows benutzt).
Die Sache ist ja die, dass die Executables zur WU-Berechnung z.B. vom Scripps-Institute (für Predictor) kommen, während der BOINC-Client von der Berkely-Uni bzw. von irgendjemand anders kommt, der ihn verändert und neu kompiliert hat.
Folgende EXEs werden normalerweise gestartet:
boinc.exe (vom Client)
boincmgr.exe (vom Client)
z.B. mfoldB125_4.28_windows_intelx86.exe (vom Predictor-Projekt)
Die ersten beiden werden vom Client mitgeliefert und die letzte wird vom Client erst selbst heruntergeladen. Das heisst, der Client fragt beim Projekt an und bekommt dann die URL zum Download der mfoldB125_4.28_windows_intelx86.exe. Somit lädt auch der optimierte Client dieselbe mfoldB125_4.28_windows_intelx86.exe herunter. Und genau diese ist es, die die ganze Arbeit erledigt.
Aus diesem Grund ist die WU-Berechnung mit einem optimiertem Client nicht schneller!
Was der optimierte Client überhaupt bewirkt...
Aufgrund erweiterter Befehlssätze (z.B. SSE, SSE2, SSE3) sind moderne Prozessoren in der Lage gewisse Dinge schneller bzw. effizienter zu berechnen. Diese besonderen Befehle müssen aber bei der Entwicklung eines Programms explizit benutzt werden um den Geschwindigkeitsvorteil auch nutzen zu können.
Nun gibt es wie oben beschrieben zwei Arten von Executables bei BOINC. Und beide führen Berechnungen durch. Zwar sehr unausgewogen, aber dennoch.
Der Client berechnet keine WUs. Aber er führt den CPU-Benchmark durch.
Nochmal: Der Benchmark ist Teil des Clients und hat mit der WU-Berechnung nicht die Bohne zu tun. Aufgrund der Benchmarkwerte wird z.B. auch eine hochgerechnete/geschätzte Zeit für die Berechnung einer WU im BOINC-Manager angezeigt.
Der einzige effektive Sinn und Zweck des Benchmarks ist aber die Berechnung eines claimed credits für jede WU. Das wird wieder vom Client gemacht. Der nimmt sich im Anschluss an die Berechnung einfach nur die verbrauchte CPU-Zeit vom Executable und setzt die zusammen mit den Benchmark-Ergebnissen in irgendeine Formel (mit weiteren Variablen) ein und schwupps kommt der claimed credit heraus...
Zweck der Optimierung ist nun folgender: Wenn die EXE vom Predictor z.B. SSE(2) unterstützen kann, der Benchmark aber nicht (und das kann er offensichtlich im Original-Zustand nicht), ist dein Rechner bei der WU-Berechnung schneller als vom Benchmark vorher vorhergesagt. Das wäre ja egal, wenn die claimed credits nicht davon abhingen. D.h. du bringst den Benchmark auf die Performance, die bei den WUs schon lange anliegt (der Benchmark hat vorher immer das System UNTERschätzt!).
Dass diese UNTERschätzung tatsächlich vorlag, erkennt man daran, dass die vorhergesagte Zeit pro WU exakter (und NICHT zu kurz!!) ist als vorher!
Ein anderer Fall wäre es, wenn die Predictor-EXE SSE(2) nicht benutzt. Dann würde der Benchmark die WU-Berechnung ÜBERschätzen. Das würde in einer zu kurzen Vorhersage für die WU-Berechnung resultieren. Damit würdest du quasi "cheaten"... (Predictor benutzt SSEx)
Damit hat die Optimierung nichts mit den WUs zu tun (da müsste eine Optimierte EXE vom Predictor kommen), sondern nur mit der credit-Berechnung...
Warum der granted credit trotz optimiertem Client nicht unbedingt höher sein muss...
Also nochmal folgende Zusammenfassung, die aufschlüsseln sollte was der optimierte Client maximal herausholen kann:
Der optimierte Client ändert wie oben beschrieben die claimed Credit-Werte die dein Rechner anfordert, wenn eine WU fertig berechnet ist.
Jede WU wird von mehreren Clients berechnet um die Ergebnisse zu vergleichen
Der claimed Credit eines jeden Rechners berechnet sich aus verbrauchter CPU-Zeit und dem Benchmark-Ergebnis des Clients
(da das Benchmark Ergebnis mit dem optimierten Client besser ausfällt, gibt es hier mehr Punkte)
Nach diesen Regeln wird aus den claimed Credits der gelieferten Resultate ein granted Credit für alle Berechner derselben WU berechnet.
Somit gilt folgendes:
War der Rechner schon immer ein Low-Performer (also niedriger claimed Credit: es wird fast immer der Credit anderer gegranted, z.B. claimed unter 6) kann es sein, dass sich der optimierte Client als Nachteil bemerkbar macht. Wenn man nämlich in das Mittelfeld rutscht und damit die Wahrscheinlichkeit erhöht, dass der eigene Credit gegranted wird, der zwar besser aber immernoch niedrig ist. Hier ist es vielleicht besser, sich darauf zu verlassen, denn Credit der anderen zu bekommen...
Für High-Performer (z.B. claimed Credits > 20) kann man den optimierten Client installieren. Er bringt aber vermutlich nicht so extrem viel, weil auch bisher kaum claimed Credit der jeweiligen Maschine wirklich gegranted wird. Man verringert eher die Wahrscheinlichkeit. Aber schaden wird es vermutlich nicht.
Für die Rechner im Mittelfeld (claimed Credit so um die 10) Macht das am meisten Sinn, würde ich sagen. Die Wahrscheinlichkeit ist recht hoch, dass man nicht schlechtester oder besser wird und daher den gegranteten Wert erhöht.
Mein 1,3GHz Tuleron ist da ein gutes Beispiel: für eine bprion-WU ist der claimed-Wert von ca. 14 auf ca. 16 gestiegen. Damit hängt er irgendwo zwischen Mittelfeld und High-Performer. Es wurde in der Vergangenheit bei etwa jeder 3.-4. WU von mir der claimed Credit gegranted. Bei ca. 15 WUs pro Tag und 1/3 eigener Quote kann man also ca. 10 Credits pro Tag mehr effektiv herausbekommen (5*14=70 vs. 5*16=80)...
Viel mehr ist nicht drin. Das ist also kein Wundermittel...
(Anmerkung von mir) Lest meinen unteren Tread dann werdet Ihr sehen das OPTICLIENTS niemanden etwas bringen... NICHT BEI SPINHENGE!
(Quelle: Meisterkuehler.de)
Zuletzt bearbeitet:
Olivier
Grand Admiral Special
das sehe ich auch so, finds eh verdammt blöd zu sagen "die version ist illegal und die darfst nehmen", denn tatsache ist man kann nicht besch... den alle WUs werden auf 3 rechner verteilt und nach fertigrechnen derer auf den 3 rechner gegranted und zwar mit dem durchschnittswert, sprich hat
- PC A 10
- PC B 15
- PC C 25
erwirtschaftet wird am Ende der berechnung durch Spinhenge
10
15
25 = 50 / 3 PCs = 16,66 Credits für alle 3 Rechner verteilt.
Somit sieht man das es kompletter unsinn ist einen optimierten client zu benützen, da in dem Moment wenn es ein User tut er indirekt auch die Gegner unterstützt, denn die WUs werden wahllos verteilt, aber immer auf 3 Rechner, das heißt das kein User eine Unique WU hat wie bei SETI, hier profitieren immer 3, wenn du glück hast sind es deine teamkollegen, im pechfalle 2 Deiner gegner...
Darüber sollte gesprochen werden dann hört nämlich die Diskussion um Turbo Clients ganz schnell auf... Und alle benützen eine normale... nämlich wie die 5.8.15 das ist die offiziell letzte von Berkeley...
Wenn man sich diese tatsachen vor Augen führt und kurz überlegt (schaut euch die WUs an auf wen die alle gleichzeitig verteilt werden in euerem Boinc)
dann kommt man zum Schluss:
ES GIBT SOMIT (meiner Meinung nach) KEIN CHEATEN BEI SPINHENGE es ist schlicht nicht möglich durch oben genannte Gründe! Vielleicht woanders aber nicht bei Spinhenge...
Lasst uns Schluss machen mit dieser niemand nützenden "Illegal oder Legal Version" Diskussion, es soll jeder selber entscheiden was er macht, ich benütze die normal letzte von berkeley...Auf dem Papier mag das zwar irre schick aussehen mit den Zahlen, aber dafür hängt es erst im pending und am ende bekommst du doch nur den durchschnitt, vielleicht ist das die Art wie Spinhenge sich vor solchen Sachen schützt... Ich finds nicht schlecht, gute Präventiv massnahme.... Ich denke mal das dem so ist, sonst würde SH nicht die WUs verteilen.. Berichtigt mich ruhig falls ich mich täusche, aber ich denke nicht das ich da massiv danebenliege... Was da noch im Detail genau vergeben wird wegen CPU Leistung und sonstigem ist auch mir nicht bekannt (Euch?) Aber so ähnlich muss es sein...
- PC A 10
- PC B 15
- PC C 25
erwirtschaftet wird am Ende der berechnung durch Spinhenge
10
15
25 = 50 / 3 PCs = 16,66 Credits für alle 3 Rechner verteilt.
Somit sieht man das es kompletter unsinn ist einen optimierten client zu benützen, da in dem Moment wenn es ein User tut er indirekt auch die Gegner unterstützt, denn die WUs werden wahllos verteilt, aber immer auf 3 Rechner, das heißt das kein User eine Unique WU hat wie bei SETI, hier profitieren immer 3, wenn du glück hast sind es deine teamkollegen, im pechfalle 2 Deiner gegner...
Darüber sollte gesprochen werden dann hört nämlich die Diskussion um Turbo Clients ganz schnell auf... Und alle benützen eine normale... nämlich wie die 5.8.15 das ist die offiziell letzte von Berkeley...
Wenn man sich diese tatsachen vor Augen führt und kurz überlegt (schaut euch die WUs an auf wen die alle gleichzeitig verteilt werden in euerem Boinc)
dann kommt man zum Schluss:
ES GIBT SOMIT (meiner Meinung nach) KEIN CHEATEN BEI SPINHENGE es ist schlicht nicht möglich durch oben genannte Gründe! Vielleicht woanders aber nicht bei Spinhenge...
Lasst uns Schluss machen mit dieser niemand nützenden "Illegal oder Legal Version" Diskussion, es soll jeder selber entscheiden was er macht, ich benütze die normal letzte von berkeley...Auf dem Papier mag das zwar irre schick aussehen mit den Zahlen, aber dafür hängt es erst im pending und am ende bekommst du doch nur den durchschnitt, vielleicht ist das die Art wie Spinhenge sich vor solchen Sachen schützt... Ich finds nicht schlecht, gute Präventiv massnahme.... Ich denke mal das dem so ist, sonst würde SH nicht die WUs verteilen.. Berichtigt mich ruhig falls ich mich täusche, aber ich denke nicht das ich da massiv danebenliege... Was da noch im Detail genau vergeben wird wegen CPU Leistung und sonstigem ist auch mir nicht bekannt (Euch?) Aber so ähnlich muss es sein...
Zuletzt bearbeitet:
algeron
Grand Admiral Special
Bitte kein Vollzitat posten 
Du solltest besser nur einzelne Abschnitte zitieren und die Quelle am besten direkt verlinken
Du solltest besser nur einzelne Abschnitte zitieren und die Quelle am besten direkt verlinken
Olivier
Grand Admiral Special
Bitte kein Vollzitat posten
Du solltest besser nur einzelne Abschnitte zitieren und die Quelle am besten direkt verlinken
oki doki, mach ichs nächste mal... dachte Quelle nennen reicht, wobei untere Berechnung und Schlussfolgerung von mir stammt... (wollte keine Werbung für anderen Foren machen, deswegen) und ich finds praktischer wenn man alles auf einnmal lesen kann...
Zuletzt bearbeitet:
algeron
Grand Admiral Special
editieren
Ich habe das nur geschrieben, weil das Urheberrecht an dem von Dir geposteten Text wohl nicht bei Dir liegt. Der Verweis auf ein anderes Forum ist völlig problemlos
Olivier
Grand Admiral Special
jo is jut.... 
Zuletzt bearbeitet:
Ähnliche Themen
