BOINC: New credit system design

Grid-Computing, technische Entwicklung von Distributed Computing...
Nachricht
Autor
Benutzeravatar
Myrmidon
Brain-Bug
Brain-Bug
Beiträge: 542
Registriert: 04.10.2007 17:55

Re: BOINC: New credit system design

#13 Ungelesener Beitrag von Myrmidon » 09.11.2009 13:12

vfrey hat geschrieben: ich zweifle massiv an der Verhältnismässigkeit der zu erzielenden Credits. Mit meiner GraKa erziele ich in 24 Stunden
- bei Collatz ca. 25.000 credits
- bei GPUGRID ca. 9.000 credits
- bei SETI ca. 5.500 credits
Ich bin der Überzeugung, dass dieses....ich will es nicht mal Problem nennen....durch das neue Creditsystem nicht großartig anders wird. Denn so wie ich dass verstanden habe (korrigiert mich) sollen sich die Credits für die Gpu-Apps aus den Cpu-Anwendungen berechnen. Und wenn ein spezielles Problem nun mal gut parallelisierbar ist, und die GPU möglichst effizient auslastet (sagen wir 80 % der maximalen Rechenleistung), dann gibts automatisch mehr Punkte, mit derselben Hardware, als bei anderen. Und dass die Effizenz da sehr stark schwanken kann, sieht man daran, dass hier von 10% geredet wird, während dessen Gipsel bei seiner Milkyway-app von bis zu 70% redet (Quelle).
Hier wurde der Creditunterschied also Faktor 7 betragen, wobei ja auch tatsächlich sieben mal so viel Arbeit geleistet wurde.

Ok wie genau sich das mit deiner GPU und den von dir genannten Projekten darstellt kann cih natürlich nicht sagen. Ich vermute auch, dass Collatz etwas zu viele cpd vergibt, aber nicht in dem Maße, wie manche vieleicht denken.

edit:
L3v3l0rd hat geschrieben: Nichtsdestotrotz geht es bei den Credits in erster Linie um Motivation und die (so find ich auch) leidet einfach wenn jemand mal eben mit 30.000 Credits vorbeirauscht. Man fühlt sich als User irgendwie verschaukelt, obwohl es ja nicht so ist. Die Werte sind einfach zu weit auseinander. Ich fänds gut wenn die Laufzeit der CPU/GPU stärker berücksichtigt wird, als die reine Rechenleistung; nicht aus Gerechtigkeitsgründen, sondern aus Motivationsgründen. Denn nur darum geht es bei den Credits, oder?

Gruß, L3v3l
Das lässt aber dann auch viel Spielraum für Willkühr. Ich sehe dass so, da wo mit GPUs gerechnet werden kann, haben CPUs eigentlich nix verloren, das ist nur Stromverschwendung. Das durch die GPU-Apps frei gewordene Potential kann man doch lieber auf Projekte setzen, bei denen wirklich nur mit CPU gerechnet werden kann, denn von denen gibts ja schlieslich auch eine Menge.
Bild

Bild

Benutzeravatar
EdmundBlackadder
Task-Killer
Task-Killer
Beiträge: 784
Registriert: 20.02.2008 17:56
Kontaktdaten:

völlig anderer Vorschlag:Nur die GPU-Zeit zählt (+n(WU))

#14 Ungelesener Beitrag von EdmundBlackadder » 09.11.2009 14:04

So. Jetzt sehe ich mich gezwungen auch mal meine Meinung zu sagen. Bis jetzt liegt das Problem beim User (Stichwort E-Penis) und nicht beim Projektbetreiber. Das ist falsch. Durch diese Politik stehlen sich Projektbetreiber aus der Verantwortung. Meine These: Bei GPU Projekten muss ausschliesslich die Zeit gewertet werden. Das löst nahezu alle Probleme.
-die Masse der User hat (unter-)durchschnittliche HW und wird dadurch erst motiviert, mitzumachen.
-alle Projekte sind von den Punkten/Zeit her gleich viel wert.
-es wird ein Druck auf die Projektbetreiber erzeugt, den Code effizienter zu gestalten (mehr Wissenschaft/Zeit) anstatt mit Credits die Leute zu sich zu lotsen.
-Projekte mit mehr oder weniger Parallelisierbarkeit sind gleichwertig. Ich kann ja nicht der GPU eine Schuld für ihre beschränkten Fähigkeiten geben.
-der User wählt dann seine Projekte nach hoffentlich "besseren" Kriterien aus.
-User mit leistungsstarker HW bleibt für E-Penis-Vergleiche die Anzahl abgearbeiteter WUs. Diese Zahl wird m.E. bei jedem Projekt mitgezählt, ist aber derzeit nur in Projektstatistiken abrufbar. Somit ist eine Vergleichbarkeit der Leistung gegeben (Laufzeit x Anzahl der WUs (statistisches Mittel bei zufälliger Vergabe ist gegeben).
-das bedeutet auch, dass Deadlines bzw. kleinere WUs für schwache HW angeboten werden müssen. Z.B. 8/8 Notebook WUs ergeben 1/1 normale WU.
-Projektbetreiber treten in echte Konkurrenz (vielleicht bisher gar nicht gewünscht) und müssen mit anderen (besseren) Methoden um die Gunst der Cruncher werben.
-das Gleiche würde ich dann auch für CPU-Projekte vorschlagen.
-es ist falsch, andere Kriterien für die Punktevergabe heranzuziehen, auch wenn diese wissenschaftlicher (?) wären, da dann die bisher unerwünschten (?) Effekte auftreten würden.
-das vorgeschlagene System ist transparent, einfach, nachvollziehbar, zukunftsfähig und nicht "diskutierbar".

Alles in Allem dürfte das die Masse motivieren (und um die geht es (mir hier), oder?). Es soll die Verantwortung dorthin bringen, wo sie hingehört, nämlich zum Projektbetreiber.
Probleme: Projekte ohne BOINC (z.B. f@h) sind in dieses Schema schwer einzugliedern.
Cruncher, die infolge dieser Änderungen DC verlassen würden, weine ich nicht hinterher. Menschen mit dieser Einstellung vermisst die Community sicher nicht.
Verschenke 2 Stück Lenovo T400 (Screen defekt) 4GB Laptops mit Dockingstation und 17" Monitor.
Ritschie hat geschrieben:Ich will ja nicht nur für Credits rechnen, sondern 'nen sinnvollen Beitrag leisten.

Benutzeravatar
Myrmidon
Brain-Bug
Brain-Bug
Beiträge: 542
Registriert: 04.10.2007 17:55

Re: völlig anderer Vorschlag:Nur die GPU-Zeit zählt (+n(WU))

#15 Ungelesener Beitrag von Myrmidon » 09.11.2009 14:46

EdmundBlackadder hat geschrieben:Bei GPU Projekten muss ausschliesslich die Zeit gewertet werden. Das löst nahezu alle Probleme.
Dass musst du näher erleutern...man kann darunter verstehen, wenn ich mit meiner GPU 24h rechne bekomme ich x credits. Egal ob Radeon 2400 Pro oder 5870, was ich so nicht unterschreiben würd ;)e. Ich denke aber du meinst wohl eher die Zeit pro WU, für die es einen festen Betrag an Credits gibt.
So ähnlich soll ja das neue System funktionieren (wie gesagt, so wie ich es verstanden habe). Frage ist eben nur, wieviel Credits man für eine WU bekommt. Das soll anhand der CPU-Anwendungen ermittelt werden. Wo sich mir noch nicht richtig die Frage erschlossen hat, wie das mit optimierten Anwendungen aussieht.

Um mal meine Meinung kund zu tun: Projektübergreifende Statistiken sind eigentlich sowieso Käse!!!
Bild

Bild

Benutzeravatar
EdmundBlackadder
Task-Killer
Task-Killer
Beiträge: 784
Registriert: 20.02.2008 17:56
Kontaktdaten:

Re: völlig anderer Vorschlag:Nur die GPU-Zeit zählt (*n(WU))

#16 Ungelesener Beitrag von EdmundBlackadder » 09.11.2009 15:15

Myrmidon hat geschrieben:Dass musst du näher erleutern...man kann darunter verstehen, wenn ich mit meiner GPU 24h rechne bekomme ich x credits. Egal ob Radeon 2400 Pro oder 5870, was ich so nicht unterschreiben würd ;)e.
Aber genau das meine ich. Eine WU hat keine Punkte. Es Zählt die Zeit der GPU und die absolute Anzahl der (im statistischen Mittel gleichwertigen) WUs.
Myrmidon hat geschrieben:Frage ist eben nur, wieviel Credits man für eine WU bekommt.
Nach meinem Modell keine. Problem entfällt.
Myrmidon hat geschrieben:Wo sich mir noch nicht richtig die Frage erschlossen hat, wie das mit optimierten Anwendungen aussieht.
Bei meinen Überlegungen entfällt dieses Problem.
Ergänzung:
Betreiber vieler schwacher GPUs werden mit mehr Punkten für ihren höheren Strombedarf entschädigt. Betreiber vieler schneller GPUs arbeiten viele WUs/Zeit ab und sind somit weiterhin in den Statistiken vorne.
Myrmidon hat geschrieben:Um mal meine Meinung kund zu tun: Projektübergreifende Statistiken sind eigentlich sowieso Käse!!!
Projektübergreifende Statistiken dürfte es weiterhing eben, sie haben jedoch keine Aussagekraft mehr (haben Sie heute eine? (ausser dem E-Penis)). Oder nur dann, wenn jeder alle Projelkte gleichmässig betreibt, da es sonst plötzlich nach der Anzahl der WUs gehen würde. Ich kann auch auf einem beliebigen durchschnittlichen Referenzrechner von jedem GPU-Projekt n WUs rechnen und dann über das Mittel die Gewichtung der WU-Laufzeit jedes Jahr neu verteilen. Als Laufzeitfaktor nur für projektübergreifende Statistiken.
Mein Ansatz ist, viele Probleme zu umgehen und mit den verbleibenden Kompromissen zu leben.
Verschenke 2 Stück Lenovo T400 (Screen defekt) 4GB Laptops mit Dockingstation und 17" Monitor.
Ritschie hat geschrieben:Ich will ja nicht nur für Credits rechnen, sondern 'nen sinnvollen Beitrag leisten.

Benutzeravatar
Uwe Sänger Herzke
Block-Bunkerer
Block-Bunkerer
Beiträge: 1326
Registriert: 31.05.2006 14:33
Wohnort: Bremen
Kontaktdaten:

Re: BOINC: New credit system design

#17 Ungelesener Beitrag von Uwe Sänger Herzke » 09.11.2009 15:21

Der Ansatz von Edmund bedeutet:
Viele alte Schrottsysteme, die vor allem Strom verbrauchen aber nix schaffen, werden gegenüber modernen Systemen, die bei wenig Stromverbrauch viel Arbeit wegschaffen klar bevorzugt.
Eine imho sehr schlechte Lösung, mit genau den falschen Anreizen zum Stromverschwenden. Am Besten wären dann vermutlich dutzendweise parallele VMs auf der gleichen Maschine, die, da sie sich gegenseitig behindern, natürlich sehr lange brauchen, aber das ist ja egal, Effektivität soll ja bestraft werden gegenüber massenhaftem Schrott.

Nein, vergleichbare Wutzen sollten auch in etwa die gleichen Credits bekommen, gleicher Lohn für gleiche Arbeit. Das Problem besteht allerdings bei der Definition von "gleicher Arbeit", damit darf auf keinen Fall verbrauchter Strom gemeint sein.
Grüße vom Sänger
Bild Bild Bild

Benutzeravatar
EdmundBlackadder
Task-Killer
Task-Killer
Beiträge: 784
Registriert: 20.02.2008 17:56
Kontaktdaten:

Re: BOINC: New credit system design

#18 Ungelesener Beitrag von EdmundBlackadder » 09.11.2009 15:26

@Sänger: Du hast mich leider nicht verstanden. Ich habe gross und breit erklärt, dass da die Anzahl der WUs für die Punkte mitberücksichtigt werden. Deine Vorgehensweise bringt nach meinem System nicht mehr Punkte, sondern weniger.
Beispiel 1:
Fix: 5000 Punkte/GPU/Tag.
Ich habe 8 langsame GPUs, die an 1 Tag je 1/8 WU schaffen. Rechnung: 5000 * 8 GPUs * 1/8 WU
Du hast eine schnelle GPU, die an 1 Tag 1 WU schafft. Rechnung: 5000 * 1 GPU *1 WU
Beide bekommen also die gleichen Punkte/Tag. Punkte/Tag ist fix (neu!). Punkte/WU ergeben sich automatisch nach Laufzeit (neu!). Also: Je schneller die HW, desto mehr Punkte. Punkte ~ n(Tage). Punkte ~ m(WUs). Anzahl der WUs bezogen auf das gleiche Projekt (wie oben beschrieben)!
Sänger hat geschrieben: Nein, vergleichbare Wutzen sollten auch in etwa die gleichen Credits bekommen, gleicher Lohn für gleiche Arbeit. Das Problem besteht allerdings bei der Definition von "gleicher Arbeit", damit darf auf keinen Fall verbrauchter Strom gemeint sein.
Genau das ist fatal. Meine Berechnung basiert auf 24h. Diese Grösse ist fix. Somit entfällt der ewige und nervige Dauerstreit mit wieviele Punkte/WU. Die unterschiedlichen WUs gleichen sich in meiner Berechnung im statistischen Mittel aus. Ich umgehe somit die Diskussion Punkte/WU, berücksichtige aber die Anzahl der WUs bei der Creditvergabe (gleiches Projekt, Erläuterung oben).
Bei mir heisst es nicht: "Gleiche Punkte" für "gleiche Arbeit", sondern "mehr Punkte für schnellere Arbeit" und "weniger Punkte für langsamere Arbeit". Und damit ist genau Dein Kriterium von "Effektivität wird bevorzugt" erfüllt.
Beispiel 2:
Jeweils gleicher PC mit gleicher GPU.
Projekt a: 5000 Punkte/Tag, GPU schafft 3 WUs. Rechnung 5000 * 3 = 15000 Punkte
Projekt b: 5000 Punkte/Tag, GPU schafft 2 WUs. Rechnung 5000 * 2 = 10000 Punkte
Für die projektübergreifenden Statistiken werden auf einem Referenz-PC jedes Jahr n WUs von jedem (GPU-)Projekt gerechnet und die unterschiedlichen n (WU)/Tag mit Ausgleichsfaktoren herausgerechnet.
Wenn Rosinenpicken bald auch nicht mehr möglich sein wird, sehe ich aktuell keine Möglichkeit, das System zu betrügen.
Wenn ich nicht völlig bescheuert bin, funktioniert meine Theorie. Wenn nicht, dann bitte ich um einen Gegenthese bzw. -beweis.
Verschenke 2 Stück Lenovo T400 (Screen defekt) 4GB Laptops mit Dockingstation und 17" Monitor.
Ritschie hat geschrieben:Ich will ja nicht nur für Credits rechnen, sondern 'nen sinnvollen Beitrag leisten.

Benutzeravatar
Myrmidon
Brain-Bug
Brain-Bug
Beiträge: 542
Registriert: 04.10.2007 17:55

Re: BOINC: New credit system design

#19 Ungelesener Beitrag von Myrmidon » 09.11.2009 16:41

EdmundBlackadder hat geschrieben:@Sänger: Du hast mich leider nicht verstanden. Ich habe gross und breit erklärt, dass da die Anzahl der WUs für die Punkte mitberücksichtigt werden. Deine Vorgehensweise bringt nach meinem System nicht mehr Punkte, sondern weniger.
Beispiel 1:
Fix: 5000 Punkte/GPU/Tag.
Ich habe 8 langsame GPUs, die an 1 Tag je 1/8 WU schaffen. Rechnung: 5000 * 8 GPUs * 1/8 WU
Du hast eine schnelle GPU, die an 1 Tag 1 WU schafft. Rechnung: 5000 * 1 GPU *1 WU
Beide bekommen also die gleichen Punkte/Tag. Punkte/Tag ist fix (neu!). Punkte/WU ergeben sich automatisch nach Laufzeit (neu!). Also: Je schneller die HW, desto mehr Punkte. Punkte ~ n(Tage). Punkte ~ m(WUs). Anzahl der WUs bezogen auf das gleiche Projekt (wie oben beschrieben)!
Sry, aber dass du das so meinst konnte man aus deinen Erleuterung definitiv nicht rauslesen!

mal konkret zu deinem System:
- Was ist, wenn ich extrem kurze WUs habe und davon mit einer GPU 2/Tag schaffe?...10.000 cpd
- Was wenn ich mit demselben System längere WUs bearbeiten muss, sagen wir 0,5 WUs/Tag?...2.500 cpd
Ob das nun Projektübergreifend ist spielt dabei erstmal gar keine Rolle, da sich auch innerhalb eines Projekts WUs mit verschiedenen Laufzeiten ergeben.
Bild

Bild

Benutzeravatar
yoyo
Vereinsvorstand
Vereinsvorstand
Beiträge: 8045
Registriert: 17.12.2002 14:09
Wohnort: Berlin
Kontaktdaten:

Re: BOINC: New credit system design

#20 Ungelesener Beitrag von yoyo » 09.11.2009 17:27

Hallo,

aus meiner Sicht sind die Credits eine Projektes nicht das Problem. Keiner beschwert sich darüber, dass SOB oder Folding@home zu viel/wenig credits gibt im Vergleich zu SETI oder Collatz.
Die Ursache der ganzen Credit Diskussion liegt daran, dass die Projekte miteinander verglichen werden und dass dazu die absoluten Credits eines Projektes genommen werden.
Keiner bezieht z.B. Folding@home mit ein, weils kein Boinc Projekt ist.

Daher sollten die Projektvergleichseiten nicht die absoluten credits nehmen, sondern eine allgemeine Normierung vornehmen. Beispiele dazu gibts ja bereits:
- DC-Vault, vergleicht sogar Boinc und nicht-Boinc Projekte
- boincstats worldcup points

Dann wäre es egal, wieviel Credits ein Projekt im Vergleich zu anderen gibt.

yoyo
HILF mit im Rechenkraft-WiKi, dies gibts zu tun.
Wiki - FAQ - Verein - Chat

Bild Bild

Benutzeravatar
EdmundBlackadder
Task-Killer
Task-Killer
Beiträge: 784
Registriert: 20.02.2008 17:56
Kontaktdaten:

Re: BOINC: New credit system design

#21 Ungelesener Beitrag von EdmundBlackadder » 09.11.2009 17:35

Myrmidon hat geschrieben:mal konkret zu deinem System:
- Was ist, wenn ich extrem kurze WUs habe und davon mit einer GPU 2/Tag schaffe?...10.000 cpd
- Was wenn ich mit demselben System längere WUs bearbeiten muss, sagen wir 0,5 WUs/Tag?...2.500 cpd
Ob das nun Projektübergreifend ist spielt dabei erstmal gar keine Rolle, da sich auch innerhalb eines Projekts WUs mit verschiedenen Laufzeiten ergeben.
Die unterschiedlichen Laufzeiten der WUs gleichen sich in meiner Berechnung im statistischen Mittel aller vom User berechneten WUs aus. Das ist natürlich nicht vollständig gerecht, da innerhalb eines definierten Zeitraumes (z.B. 1 Monat) z.B. nur WUs vom Typ a oder b oder c herausgegeben werden könnten (also nicht dem ganzjährigen Mittel entsprechend). Es ist aber für Rosinenpicker schwierig, da hier mehr Punkte nicht mehr so einfach zu bekommen sind. Dazu müsste der Rosinenpicker dauernd das Projekt wechseln und schauen, wo er gerade besonders kurze WUs eines Projektes bekommt und jeweils die langen WUs löschen können. Ein "Betrüger" müsste also dauernd in allen Projekten nur die jeweils kürzesten WUs rechnen, um einen gewissen Vorteil zu haben.
Jedoch hoffe ich dass das Folgendes bald greifen wird:
Wenn Rosinenpicken der besten ppd-WUs (nach den aktuellen Ankündigungen des BOINC Teams) bald auch nicht mehr möglich sein wird, sehe ich aktuell keine Möglichkeit, das System gleichmässiger Verteilung und Bearbeitung von WUs zu betrügen.
In der Gesamtstatistik werden Laufzeiten kurzer wie langer WUs durch den auf einem Referenzrechner ermittelten Korrekturfaktor für die Laufzeiten gemittelt (s.o.). Man müsste das mal an konkreten Projekten testen, wie stark die Abweichungen sind bei einer kontinuierlichen Laufzeit von z.B. 30 Tagen. Bzw. ab wieviel Laufzeit eine Abweichung vom Mittel von kleiner als z.B. 2-3% (definierte akzeptable Grösse) erreicht ist. Das wäre dann die jeweilige Laufzeit für den Referenzrechner. Hier werden die Laufzeitdifferenzen als relative Größe gemessen. Und das jedes Jahr auf's Neue mit einem aktuellen "Durchschnitts-PC".

Ich gebe zu, dass das Problem sich mit meinem Vorschlag nicht vollständig lösen lasst. Es verlagert sich nur auf andere Bereiche. Meine Herangehensweise war, dass ich o.g. Vorteile und Effekte erreichen wollte (die meiner Meinung nach wünschenswert sind), anstatt Alles an Credits festzumachen (wie bisher). Der Cruncher soll sich ohne Punktedruck frei entscheiden können, woran er sich beteiligt. Meine Idee ist: Jedes beliebige Projekt ergibt in der Gesamtstatistik die gleichen Credits auf demselben Rechner bei gleicher Laufzeit.
Zuletzt geändert von EdmundBlackadder am 09.11.2009 17:58, insgesamt 1-mal geändert.
Verschenke 2 Stück Lenovo T400 (Screen defekt) 4GB Laptops mit Dockingstation und 17" Monitor.
Ritschie hat geschrieben:Ich will ja nicht nur für Credits rechnen, sondern 'nen sinnvollen Beitrag leisten.

Benutzeravatar
Myrmidon
Brain-Bug
Brain-Bug
Beiträge: 542
Registriert: 04.10.2007 17:55

Re: BOINC: New credit system design

#22 Ungelesener Beitrag von Myrmidon » 09.11.2009 17:56

EdmundBlackadder hat geschrieben: In der Gesamtstatistik werden Laufzeiten kurzer wie langer WUs durch den auf einem Referenzrechner ermittelten Korrekturfaktor für die Laufzeiten gemittelt (s.o.). Man müsste das mal an konkreten Projekten testen, wie stark die Abweichungen sind bei einer kontinuierlichen Laufzeit von z.B. 30 Tagen. Bzw. ab wieviel Laufzeit eine Abweichung vom Mittel von kleiner als z.B. 2-3% (definierte akzeptable Grösse) erreicht ist. Das wäre dann die jeweilige Laufzeit für den Referenzrechner. Hier werden die Laufzeitdifferenzen als relative Größe gemessen. Und das jedes Jahr auf's Neue mit einem aktuellen "Durchschnitts-PC".
Wenn du die Laufzeit einer WU auf einem "Referenzrechner" ermitteln willst und dann ein Korektorfaktor einführst, dann ist das am Ende das gleiche, als legtest du die Credits für eine WU fest. Womit wir uns im Kreis gedreht hätten. Außerdem gibt es dann wieder das gleiche Problem mit der Weiterentwicklung der Anwendungen. Wenn ein Projektbetreiber seine App aufgrund von z. B. sse Erweiterung beschleunigen kann, und somit mehr WUs in kürzerer Zeit abarbeitet, dann haben wir auf einmal wieder ein Projekt, was im Vergleich zu anderen mehr Credits bei gleicher Laufzeit vergibt.
Bild

Bild

Benutzeravatar
EdmundBlackadder
Task-Killer
Task-Killer
Beiträge: 784
Registriert: 20.02.2008 17:56
Kontaktdaten:

Re: BOINC: New credit system design

#23 Ungelesener Beitrag von EdmundBlackadder » 09.11.2009 18:07

Myrmidon hat geschrieben: Wenn du die Laufzeit einer WU auf einem "Referenzrechner" ermitteln willst und dann ein Korektorfaktor einführst, dann ist das am Ende das gleiche, als legtest du die Credits für eine WU fest. Womit wir uns im Kreis gedreht hätten. Außerdem gibt es dann wieder das gleiche Problem mit der Weiterentwicklung der Anwendungen. Wenn ein Projektbetreiber seine App aufgrund von z. B. sse Erweiterung beschleunigen kann, und somit mehr WUs in kürzerer Zeit abarbeitet, dann haben wir auf einmal wieder ein Projekt, was im Vergleich zu anderen mehr Credits bei gleicher Laufzeit vergibt.
zu 1. Nein, da ich einen unabhängigen Referenzrechner habe. Und zwar nur um die Korrekturfaktoren zu ermitteln. Soweit ich weiss, legen die Projektbetreiber die Credits derzeit selber fest. Bei mir bekommen alle gleich viele Credits/Tag.
Ja, kurzfristige statistische Vorteile durch Beschleunigungen sind gewollte Effekte meines Vorschlages (oben bereits erwähnt), da hier die Projektbetreiber belohnt werden durch kurzfristig mehr beteiligte Cruncher (der Effekt dauert bsp. 1-3 Monate). Wann und wie oft der Referenzrechner läuft, muss natürlich geheim sein.
Wie gesagt, schöne Ideen helfen nichts, wenn sie in der Praxis genauso unbrauchbar sind, wie bestehende Systeme.
Verschenke 2 Stück Lenovo T400 (Screen defekt) 4GB Laptops mit Dockingstation und 17" Monitor.
Ritschie hat geschrieben:Ich will ja nicht nur für Credits rechnen, sondern 'nen sinnvollen Beitrag leisten.

Benutzeravatar
Myrmidon
Brain-Bug
Brain-Bug
Beiträge: 542
Registriert: 04.10.2007 17:55

Re: BOINC: New credit system design

#24 Ungelesener Beitrag von Myrmidon » 09.11.2009 19:14

EdmundBlackadder hat geschrieben: zu 1. Nein, da ich einen unabhängigen Referenzrechner habe. Und zwar nur um die Korrekturfaktoren zu ermitteln. Soweit ich weiss, legen die Projektbetreiber die Credits derzeit selber fest. Bei mir bekommen alle gleich viele Credits/Tag.
Ja, kurzfristige statistische Vorteile durch Beschleunigungen sind gewollte Effekte meines Vorschlages (oben bereits erwähnt), da hier die Projektbetreiber belohnt werden durch kurzfristig mehr beteiligte Cruncher (der Effekt dauert bsp. 1-3 Monate). Wann und wie oft der Referenzrechner läuft, muss natürlich geheim sein.
Wie gesagt, schöne Ideen helfen nichts, wenn sie in der Praxis genauso unbrauchbar sind, wie bestehende Systeme.
Spielt doch keine Rolle, ob der Referenzrechner unabhängig ist oder nicht. Wenn du deine 5.000 Credits pro Tag je nach WU aufstockst oder herabsetzt (Korrekturfaktor), dann entspricht das genau dem Sachverhalt, als würdest du jeder WU eine gewisse Anzahl Credits zuteilen (natürlich auch so, dass du wieder auf 5.000 cpd kommst). Das ist meiner Meinung nach nur ein hin und hergeschiebe von Zahlen nix weiter.

Wieso "kurzfristige statistische Vorteile"? Wenn ich an einer Applikation Performanceverbesserungen vornehme, dann sind die gewinne i. d. R. dauerhaft. Und der Performancegewinn kommt dann nicht nur durch mehr beteiligte cruncher, sondern eben durch mehr Durchsatz pro host.

Das du mit deinem System in etwa eine projektübergreifende Vergleichbarkeit bereitstellst, liegt schlicht und ergreifend daran, dass alle WUs dem selben Performance-test unterliegen. Nämlich dem, auf dem Referenzrechner.

Ich bestreite ja nicht, dass die Idee gut ist, aber sie beruht vereinfacht gesagt nur darauf, dass auf einem zentralen Rechner getestet wird, wie lange eine WU dauert und dann die entsprechenden Punkte vergeben werden, die es für das abarbeiten dieser gibt (ob du dass nun direkt, doer mit Korekturfaktoren machst, ist ja schnurz). Am Ende ists doch so ähnlich wie bei F@h wenn ich nicht irre?

Funktionieren kann so etwas natürlich, setzt aber voraus, dass sich alle Projektbetreiber damit einverstanden sehen und die Creditvergabe zentral organisiert ist.

yoyo hat schon recht, dass die Projekte durch dei absoluten Credits nicht miteinander verglichen werden können/sollten. Meiner Meinung nach ist alles ok, solange die Vergabe innerhalb eines Projektes vergleichbar ist.
Bild

Bild

Antworten

Zurück zu „Hintergrundinfos zu Verteiltem Rechnen“