Veränderte Punktevergabe bei GpuGrid

[Kolossus]

Die geleistete Rechenarbeit wird in den Kontocertifikaten angegeben:

This certifies that

Kolossus

has participated in POEM@HOME since 25 January 2012, and has contributed 3,413,996 Cobblestones of computation (2.95 quintillion floating-point operations) to POEM@HOME.

Warum werden diese Angaben nicht für eine Punktevergabe genutzt, das wäre doch sicher ehrlicher und sachlicher als eine inflationäre Vergabe von Punkten

[Dj Ninja]

Diese Angabe basiert ja auf den Credits.

Wenn man probiert, die Credits zwischen den einzelnen Projekten zu normalisieren (Projekt A *0.5, Projekt B *0.9, Projekt C *1.2, ...) hast Du doch gleich das nächste Problem. Erstens wirst Du die Apfelbirnenkartoffel (CPU+GPU+ASIC) nicht los und zweitens wie findet man korrekte Faktoren, die von jedem als gerecht angesehen werden? Das kann nicht funktionieren. Auch nicht zwischen verschiedenen Plattformen (Boinc und Antiboinc).

In dem Augenblick wo Credits nicht streng nach Rechenleistung (FLOPS) vergeben werden, verlieren sie diesen Bezug und es ist unmöglich, hinterher noch akkurate Rückschlüsse auf die Rechenleistung aus den Credits zu ziehen. Das haben verschiedene Projekte schon lange geschafft, spätestens seit Shitcoin Udopia ist das Creditsystem hinfällig.

[Michael H.W. Weber]

Prinzipiell hast du mit der Normierung natürlich recht... aber ich kann mir vorstellen, dass dies sehr schwer ist. Welche Genauigkeit benötigen die Ergebnisse, wie rechnet die Mikroarchitektur, unterschiedliche Betriebssysteme brauchen evtl. auch unterschiedlich viele Operationen zum lösen einer Aufgabe... Und dann noch der Vergleich CPU/GPU.

Ich sage es mal so: Selbst wenn man da etwas "falsch" macht, ist es immer noch besser und vor allem nachvollziehbarer, als diesen willkürlichen Müll hinzunehmen.
Nehmen wir mal eine MD Simulation. Da gebe ich ein zu simulierendes Zeitfenster vor und dann lasse ich die Atome herumhoppeln. Im Grunde müßte zu diesem WU-Typ eine Simulation auf einem Referenzsystem laufen gelassen werden und für deren Abarbeitung gäbe es dann definierte Credits. Alle anderen WUs desselben Typs würden dann per simplem Korrelationsfaktor auf diese bezogen werden. So wäre das System zumindest in sich konsistent.
Mann könnte es aber auch ganz doof anstellen und einfach einen FLOPS-Benchmark in BOINC auf dem Clientrechner laufen lassen und dann für jede WU die benötigte CPU-Zeit messen. Dann gäbe es letztlich Credits proportional zu den erarbeiteten FLOPs. Da wird es für diesen spezifischen Benchmark bessere und schlechtere Plattformen und Betriebssysteme geben - na und? Es ist trotzdem nachvollziehbar, wie die Credits vergeben würden. Oder anders gesagt: Zumindest würden alle einheitlich "beschissen".

PS: Von welchem Projekt redest du?

Folding@home.
Dort hatte man übrigens zu Beginn exakt dieses Referenzsystem verwendet. Bis der Referenzrechner dann irgendwann krepierte.

Michael.

[Myrmidon]

Im Grunde müßte zu diesem WU-Typ eine Simulation auf einem Referenzsystem laufen gelassen werden und für deren Abarbeitung gäbe es dann definierte Credits. Alle anderen WUs desselben Typs würden dann per simplem Korrelationsfaktor auf diese bezogen werden. So wäre das System zumindest in sich konsistent.
Mann könnte es aber auch ganz doof anstellen und einfach einen FLOPS-Benchmark in BOINC auf dem Clientrechner laufen lassen

Mh....Ich dachte immer das wird so gemacht.? Zumindest war das früher bei vielen Projekten Standard kann ich mich entsinnen.

[yoyo]

Im Grunde müßte zu diesem WU-Typ eine Simulation auf einem Referenzsystem laufen gelassen werden und für deren Abarbeitung gäbe es dann definierte Credits. Alle anderen WUs desselben Typs würden dann per simplem Korrelationsfaktor auf diese bezogen werden. So wäre das System zumindest in sich konsistent.
Mann könnte es aber auch ganz doof anstellen und einfach einen FLOPS-Benchmark in BOINC auf dem Clientrechner laufen lassen

Mh....Ich dachte immer das wird so gemacht.? Zumindest war das früher bei vielen Projekten Standard kann ich mich entsinnen.

Genau so habe ich das im Wesentlichen bei yoyo@home gemacht. Ich habe bei ecm etliche Testreihen mit verschiedenen B1 und Composite Längen gemacht. Daraus ist dann eine Formel für die credits entstanden.
Bzgl. GPU sehe ich das so, dass diese Credits NICHT von den CPU Credits zu trennen sind. Als Projekt habe ich eine Aufgabe zu erledigen, für die es X Credits gibt. Wenn die GPU (oder der ASIC) das eben hundertmal schneller macht gibts trotzdem für die Aufgabe X Credits.
Problematisch ist das nur bei den GPU-Only Projekten, die keinen CPU Vergleich haben. Aber Credits unterschiedlicher Projekte sollte man eh nicht addieren ohne sie zu normieren.

[Myrmidon]

Mit den gleichen Credits für CPU und GPU stimme ich dir insofern zu, wenn sie wirklich die gleichen Aufgaben rechnen. Dann sind die CPUs sowieso für das jeweilige Projekt ineffektiv und viele User werden dazu motiviert auf ihren Prozessoren die CPU-Only Projekte zu rechnen. Wenn ein Projekt aber Aufgaben aufgrund der Genauhigkeit oder Komplexität oder was weiß ich nur auf CPUs ausführen kann aber auch andere Aufgaben für GPUs hat, dann fände ich eine Trennung in GPU- und CPU-credits sinvoll. Schon allein aus Interesse des Projektbetreibers heraus, die Leute zu animieren auch die CPU-WU zu rechnen. Der Betrag der Credits könnte ja gleich bleiben.

Meine Meinung

[Tholo]

Vielleicht schaut ihr euch mal die Lösung an, wie die Belohnung bei Gridcoin geregelt ist. Natürlich gilt das nur für ausgewählte Projekte, trotzdem muss CPU, Gpu und Asic Miner Arbeit verglichen werden. http://wiki.gridcoin.us/Proof-of-Research der Punkt bei Proof of Boinc zeigt euch die Formel welche verwendet wird.
Aber Vorsicht bei dieser Lösung werden die Credits nur innerhalb des Teams verglichen.
Aber daher kenne ich diese Diskussion auch. Bei Gridcoin war es so als die Asic Miner für Bitcoin Utopia eingestiegen sind.

Ich hab es bei Gpugrid mittlerweile auf Platz 1012 Weltweit geschafft. Aber auch nur wenn ich den Rechner 24/7 gelaufen ist,schmeißt Gpugrid mit Punkten um sich. So habe ich mal 1000000 Credits geschafft pro Tag . Da freut sich aber nur der Stromzähler... 440w......

[Dj Ninja]

Bei Shitcoins stört mich, daß es Parallelen zu modernen Schneeballsystemen gibt. Die ersten, die mit Schwierigkeit Null "Geld geschürft" haben, sind die großen Gewinner, alles was heute nachziehen möchte hat eigentlich keine Chance mehr. Das ist bei Schneeballsystemen genauso, die ersten gewinnen ohne jeden Einsatz und der ganze Rest bezahlt. Das hat nichts mit distributed computing zu tun, wo es irgendwann mal darum ging, die ungenutzte Rechenzeit eines Prozessors sinnvoll zu verwerten.

Wenn ich die Credits anhand der zur Verfügung gestellten Rechenleistung (FLOPS) vergeben möchte, dann kann ich sie nicht ohne weiteres für ein abgeliefertes Arbeitsvolumen vergeben. Das wird vor allem bei angepasster Hardware problematisch. Bestimmte Aufgaben lassen sich auf ASICs oder FPGAs innerhalb eines einzigen Arbeitstaktes erledigen, wofür eine "echte CPU" einen Programmdurchlauf mit sagen wir 200 Takten benötigt. Die CPU ist dafür universell einsetzbar, die ASICs/FPGAs können nur diese eine Aufgabe lösen. Einfach mal 3 durch 3 teilen geht nicht, was für eine CPU heute eine echte Unterforderung ist.

Das ist auch das Problem wieso die Boinc Credits zwischen den Projekten so unterschiedlich gewichtet sind. Irgendwo waren Cobblestones mal ganz klar definiert... Moment ...

1/200 day of CPU time on a reference computer that does 1,000 MFLOPS based on the Whetstone benchmark

Quelle: http://boinc.berkeley.edu/wiki/Computation_credit

So, wieviel MFLOPs erreicht eine Grafikkarte im Whetstone-Benchmark? Oder ein ASIC miner? Erstere wird gar nicht so schlecht abschneiden, aber für den nicht darauf ausgelegten ASIC wird's wohl schwer.

Um das Creditsystem konsistent zu halten, hätte also ausschließlich Benchmarkwert und Rechenzeit verwurstet werden dürfen. Diese Rechnung ist lange hinfällig und somit das komplette Creditsystem. Dieser Fehler ist auch nicht korrigierbar. Fällig und konsequent wäre eigentlich ein Reset des Creditsystems und anschließend eine Aufspaltung in CPU/GPU/ASIC, sowie eine bindende Verpflichtung der Projekte, sich zukünftig an die global vorgegebenen Formeln zu halten. Alles was sich nicht an die Formeln hält entspricht nicht der Definition und kann somit auch nicht einfach ohne Gewichtung zusammenaddiert werden. Anders bekommt man keine vergleichbaren Werte.

Warum das nicht anders funktioniert? Yen beispielsweise lassen sich mit der gleichen Arbeitszeit in deutlich größeren Mengen erarbeiten als Euro. Ich arbeite nun also in Japan und wundere mich, wieso ich hier in Deutschland nicht alle paar Tage ein neues Haus kaufen kann. Und wieso meine 1.000 Yen heute 8 Euro wert sind und morgen nur noch 7. Mit einfacher Addition kann man das nicht erklären.