Ideensammlung für ein neues Creditsystem

[magihatfertig]

Ich finde den Ansatz von Folding@home bislang am Besten. Eine Referenz-WU wird auf der Benutzer-Maschine gebenchmarkt und dann werden die zu vergebenden Credits proportional zu Leistung einer Referenzmaschine des Projektbetreibers vergütet.

das ist doch glaub ich genau das, was rosetta jetzt auch vorhat nach dem CASP

[Uwe Sänger Herzke]

Ich finde den Ansatz von Folding@home bislang am Besten. Eine Referenz-WU wird auf der Benutzer-Maschine gebenchmarkt und dann werden die zu vergebenden Credits proportional zu Leistung einer Referenzmaschine des Projektbetreibers vergütet.

Wie ich schon erwähnte, das ist ein sehr schöner Ansatz wenn die Leistung zum Berechnen der WU vorab bekannt ist. Das geht offensichtlich bei Folding und CPDN ganz gut, bei Predictor und Rosetta war'n die WUs jeweils etwa gleich lang, ich vermute also, da ginge es auch.
Bei LHC geht es definitiv nicht und bei Seti bin ich mir nicht im Klaren, ob eine einfache Abhängigkeit zwischen Azimut und Rechendauer besteht, oder ob das da auch nicht hinhaut. Außerdem gibt es ja noch die verrauschten KurzWUs, aber ich weiß nicht ob die vom Benutzer selektiert werden können. Bei den anderen Projekten kann ich nix zu sagen, außer, das die Rechendauern deutlich unterschiedlich sind, aber das ist's bei Folding ja auch. Die geschätzten Zeiten sind teilweise unterschiedlich (ist mir insbesondere bei Leiden aufgefallen), aber ob's damit hinhauen würde: k.A.

Also (imho):
Klare Kenntnisse über die Leistungsanforderungen der WU: Prädestination!
Unklare Verhältnisse: Benchmark x Zeit

[scsimodo]

Bei LHC geht es definitiv nicht und bei Seti bin ich mir nicht im Klaren, ob eine einfache Abhängigkeit zwischen Azimut und Rechendauer besteht, oder ob das da auch nicht hinhaut.

Die Länge der WUs wäre ja prinzipiell egal. Was man bräuchte wäre eine Referenz-WU und eine Referenzmaschine. Nehmen wir mal eine Maschine, die mit dem Boinc-Client unter Windows 10 Credits/h bringt. Dazu eine Referenz-WU, die auf dieser Maschine sagen wir mal 15 Minuten braucht. Schon hätten wir einen Maßstab.

Benötigt die Referenz-WU auf einer anderen Maschine 30 Minuten, dann gibt es halt nur 5 Credits/h, braucht sie nur 7,5 Minuten, dann gibt es eben 20/h. Sowas wäre denkbar. Sind zwar immer noch Ungenauigkeiten drin, aber bei weitem nicht so große wie bisher.

Das würde aber auch bedeuten, dass genau eine Referenzmaschine für alle Projekte existiert und jedes Projekt eine Referenz-WU auf dieser Maschine laufen lassen kann.

Dafür könnte ich mich auch begeistern (so es denn funktioniert, irgendwo habe ich sicher noch nen Denkfehler drin )

[Uwe Sänger Herzke]

Dafür könnte ich mich auch begeistern (so es denn funktioniert, irgendwo habe ich sicher noch nen Denkfehler drin )

Das wär wirklich das Beste, wenn es ginge.
[Edit]
Und wenn es geht, sollte es gemacht werden, wie bei CPDN und Folding)
[/edit]
Wie erwähnt ist es bei LHC (bislang) prinzipiell nicht möglich die länge der WU vorherzusagen. Es werden Flugbahnen von Teilchen im Beschleuniger berechnet, in Abhängigkeit von verschiedenen Magnetkonfigurationen, umn herauszubekommen, ob das so geht. Wenns nicht hinhaut, rauscht das teilchen in die Wand und die WU ist zu Ende, plötzlich und unerwartet und unvorhersehbar. Statt 2h nur 5min oder 1h oder 45min oder 1,5h oder.....

Und bei Seti gibt es neben den verschiedenen Azimutwinkeln, die eine Längenvariation von afaik den Faktor 4 ausmachen noch die bekannten Rausch-WUs, die nach wenigen Minuten abbrechen. Da kann mensch nicht alles über einen Kamm scheren (oder zumindest nicht dabei behaupten, das wäre fair).

Ich kann mir gut vorstellen, das es bei anderen Projekten ähnlich sein kann, das die WUs unvorhesehbar lange laufen, das die Iterationsschritte nicht klar sind, das modell-physikalische Grenzen erreicht sind, die ein weiterrechnen bis zum "eigentlichen Ende" sinnfrei machen, oder im gegenteil eine Verlängerung um etliche Rechenzyklen sinnvoll ist und erfolgt.

Ich weiß es nicht, ob und mit welchen Ausmaßen das zutrifft, aber wenn's zutrifft, haut der Prädestinationsansatz nicht mehr hin.

[scsimodo]

Wie erwähnt ist es bei LHC (bislang) prinzipiell nicht möglich die länge der WU vorherzusagen. Es werden Flugbahnen von Teilchen im Beschleuniger berechnet, in Abhängigkeit von verschiedenen Magnetkonfigurationen, umn herauszubekommen, ob das so geht. Wenns nicht hinhaut, rauscht das teilchen in die Wand und die WU ist zu Ende, plötzlich und unerwartet und unvorhersehbar. Statt 2h nur 5min oder 1h oder 45min oder 1,5h oder.....

Das wäre mit den Referenzberechnungen ja egal. Mit Hilfe der Referenz-WU erhält man ja die tatsächliche Geschwindigkeit der Maschine. Ob LHC dann zwei Minuten oder 2 Stunden braucht ist dann unerheblich, man bekommt halt dann nur die entsprechenden Credits für die Berechnungszeit. Für eine verrauschte SETI-WU mit ner 1/4h gibt es halt dann nur 2,5 Credits, für eine volle WU mit 3 Stunden dann halt 30. (kommt halt auf die Geschwindigkeit der Maschine an, evtl. sind es auch nur 1 und 12,5 Credits, oder 5 und 60 Credits).

Ist zwar auch noch nicht das Gelbe vom Ei, aber immer noch besser als die bisherige Lösung. Würde zumindest diese gefakten Benchmarks obsolet machen...

[Uwe Sänger Herzke]

Das wäre mit den Referenzberechnungen ja egal. Mit Hilfe der Referenz-WU erhält man ja die tatsächliche Geschwindigkeit der Maschine. Ob LHC dann zwei Minuten oder 2 Stunden braucht ist dann unerheblich, man bekommt halt dann nur die entsprechenden Credits für die Berechnungszeit. Für eine verrauschte SETI-WU mit ner 1/4h gibt es halt dann nur 2,5 Credits, für eine volle WU mit 3 Stunden dann halt 30. (kommt halt auf die Geschwindigkeit der Maschine an, evtl. sind es auch nur 1 und 12,5 Credits, oder 5 und 60 Credits).

Ist zwar auch noch nicht das Gelbe vom Ei, aber immer noch besser als die bisherige Lösung. Würde zumindest diese gefakten Benchmarks obsolet machen...

Ah! Ich hatte Dich falsch verstanden. Du möchtest eine projektspetifische Benchmark in Form einer Referenz-WU.
Die sollte aber nicht zu lang sein, sonst wird ja für jedes Projekt kostbare Rechenzeit zur Generierung einer Benchmark "vergeudet". Und ob diese WUs dann nicht auch "optimiert" werden könnten/würden sei einmal dahingestellt.
Das war ja eigentlich das schöne an BOINC, das der Client das für alle übernommen hat, und somit nicht alle meine 8 aktiven Projekte von Zeit zu Zeit mal nur für 'ne Benchmark rechnen.

[scsimodo]

Ah! Ich hatte Dich falsch verstanden. Du möchtest eine projektspetifische Benchmark in Form einer Referenz-WU.

So ist es

Ich hatte mit Thomas Rattei/SIMAP vor ca. 2 Wochen "nebenher" den Mac Intel Client gestestet, da gab es auch Test-WUs, die waren max. 10 Minuten lang. Sowas für jedes Projekt und gut is'. Die rechnet man ja nur einmal, solange der Rechner die gleiche Konfiguration hat muss man ja nicht alle paar Tage einen neuen Benchmark rechnen. Sobald sich die RAM-Konfiguration oder gar die CPU ändert, dann schon. 10 Minuten sind da einmalig nicht zuviel, denke ich. Wenn sich die Projekt-Applikation ändert müsste man natürlich wieder einen kleinen Benchmark fahren und mit der auf der Referenzmaschine vergleichen. Das kann aber auch in ein paar Minuten erledigt sein...

Die Referenz-WU müsste aber sorgfältig ausgewählt werden sprich: repräsentativ sein. FLOPS und MIPS sollten so verteilt sein wie es in der großen WU auch ist, Vor und Nachbrechnungen sollten analog viel Zeit brauchen etc. pp.

[Michael H.W. Weber]

Das würde aber auch bedeuten, dass genau eine Referenzmaschine für alle Projekte existiert und jedes Projekt eine Referenz-WU auf dieser Maschine laufen lassen kann.

Das ließe sich zumindest für die BOINC-basierten Projekte vielleicht so organisieren, daß diese Referenzmaschine in Berkeley steht.

Michael.

[Uwe Sänger Herzke]

Aus den Entwicklermailinglisten:

Zitat von Eric J Korpela
[boinc_dev] Need for a cross project credit standard.... Inbox

Eric J Korpela to BOINC
More options Jun 29

Given the recent SETI@home credit/optimization flame wars and what is happening with Einstein's recent apps, I think we need to come up with a cross project credit standard. The original idea in BOINC was to give credit for floating point, integer operations, disk space used, etc. The primary problem with the method originally used to grant credit was that it was based upon benchmarks that gave performance that was unrealistically high for the real applications. When SETI@home transitioned to granting credit based upon floating point operations we had to stick in a multiplier of about 3.5X the floating point operation count in order to match the credit given based upon the benchmarks.

This caused an uproar for a variety of reasons. The first was that the new version of SETI@home was more highly optimized than the old version, so people running optimized versions couldn't claim 5X the credit of people running unoptimized versions. The second was that "fast machines" saw a decrease in credit granted per hour (primarily because a 3GHz machine doesn't typically have memory that is 50% faster than a 2GHz machine).

Einstein@home has also recently started using FLOP counting in its applications. Perhaps in response to the furor on the SETI@home forums, E@H grants significantly higher credit per hour (2X-4X) in its FLOP counting version than in its older versions.

I worry that this lack of a standard is going to result in "credit inflation" where in respose to actions by other projects and due to complaints from a vocal minority of volunteers, projects are forced into granting ever increasing number of credits per hour.

I think we need to develop a credit standard in order to prevent this. This credit standard should 1) be measureable on a common machine (possibly on every machine) 2) be publicly available 3) specify means of comparing applications 4) reward optimization.

Lacking other suggestions, I propose to create a "standard" (non-vectorized, Ooura FFT, gcc -O2 compiled) version of SETI@home enhanced with a "standard" workunit as a credit standard. Based upon run-time and floating point operations of this standard, other projects can calibrate their floating point credit for a (non-vectorized, gcc -O2 compiled) version of their own application.

If anyone has a better idea, or would prefer that there be no standard, speak up.

Eric

Hier der Übersetzungsversuch (ohne Formalia, stehende Begriffe ggf. zur Wikipedia verlinkt):

Notwendigkeit eines projektübergreifenden Creditstandards

Angesichts der aktuellen SETI@home Credit/Optimalisierungs Flamewars und was gerade mit den aktuellen Einsteinanwendungen passiert denke ich, wir müssen einen projektübergreifenden Creditstandard entwickeln. Die Originalidee von BOINC war es Credit für Gleitkomma- und Ganzzahloperationen, benutzten Festplattenplatz usw. zu vergeben. Das Hauptproblem mit dem Methode, die zunächst benutzt wurdewar, das der Credit auf Grundlage von Benchmarks berechnet wurde, die unrealistisch hohe Leistungswerte für die richtigen Anwendungen ergab. Als SETI@home für die Creditvergabe auf die Zählung der Gleitkommaoperationen (FLOPs) umgeschwenkt ist musste ein Multiplikator von 3,5 eingeführt werden um den Credit an die alte Benchmarkmethode anzupassen.

Dies verursachte einen Aufruhr aus verschiedenen Gründen. Zum einen war die neue SETI@homeversion besser optimiert als die alte, sodaß Leute, die optimierte Versionen laufen ließen nicht mewhr den fünffachen Credit wie diejenigen mit unoptimierten Versionen fordern konnten. Zum zweiten beobachteten "schnelle Maschinen" einen Rückgang der stündlichen Creditrate (vor allem, weil eine 3GHz-Maschine üblicherweise keinen 50% größeren Speicher hat wie eine 2GHz-Maschine).

Einstein@home hat auch kürzlich das FLOP-Zählen in seinen Anwendungen angefangen. Vielleicht als Antwort auf den Furor in den SETI-Foren gewährt E@H deutlich mehr Credit pro Stunde (2x - 4x) als mit den alten Anwendungen.

Ich befürchte, das dieses fehlen eines Standards zu einer "Creditinflation" führen wird, bei der andere Projekte durch Beschwerden einer lautstarken Minderheit der Freiwilligen gezwungen werden immer mehr Credit pro Stunde zu vergeben.

Ich denke, wir müssen einen Creditstandard entwickeln, um dies zu verhindern. Dieser Standard sollte 1) messbar auf einer gewöhnlichen Maschine sein (am besten auf jeder Maschine) 2) öffentlich verfügbar sein 3) Hilfmittel bestimmen zum Vergleich der Anwendungen und 4) Optimierungen anerkennen.

In Ermangelung anderer Vorschläge schlage ich vor, eine "Standardversion" (nicht vektorisiert, Ooura FFT, gcc -O2 kompiliert) von SetiEnhanced mit einer "Standard-WU" als Creditstandard zu nehmen. Basierend auf der Laufzeit und den Gleitkommaoperationen dieses Standards könne andere Projekte ihren Gleitkommacredit für ihre (nicht vektorisierte, Ooura FFT, gcc -O2 kompilierte) Anwendung kalibrieren.

Wenn jemand eine bessere Idee hat, oder keinen Standard wünscht, möge er sich melden.

Danke an Tony (mmciastro) für das posten in den Projektforen (wo ich's her habe, selber krieg ich die dev-mail nicht)

[aalerich]

Hmmm...

Wenn ich das richtig verstehe heißt das, daß Leute mit älteren Athlon XP / Durons verar***t werden. Deren Prozessoren haben nur SSE 1 und sind daher im Gleitkommabereich vergleichsweise schwach. Da viele Projekte aber hauptsächlich Integerleistung brauchen... Selbst die aktuellen AMDs sind meines Wissens nach im Gleitkommabereich schwächer als Intel und würden auch benachteiligt werden, trotz (dank etwas besserer Integerleistung) gleicher Rechenarbeit.

Kurz: Käse.

Mit freundlichen Grüßen
aalerich

[nico]

Wenn ich das richtig verstehe heißt das, daß Leute mit älteren Athlon XP / Durons verar***t werden. Deren Prozessoren haben nur SSE 1 und sind daher im Gleitkommabereich vergleichsweise schwach.

Hmm also ich verstehe das "non-vectorized" so, dass eben kein SSE und Ähnliches benutzt werden soll. Die -O2 Option sollte das auch nicht tun. Allerdings sollten hier Intel CPUs trotzdem noch im Vorteil sein - wenn auch nicht so extrem wie mit SSE-Funktionen.

[Miko]

Auf meinen Aufruf "Ideensammlung für ein besseres Creditsystem" den ich im mehreren deutschen Fora gestartet hatte kamen einige gute Ideen. Habe sie an Eric (Korpela) nach Berkeley geschickt. Er befasst sich mit dem Thema und hat die Userideen in den BOINC Workshop einfliessen lassen...

Ich habe manche Posts etwas gekürzt und unsachliche Kommentare ausgelassen.

SIMAP Forum
(http://boinc.bio.wzw.tum.de/boincsimap/ ... =3850#3850)

Athlonheizer:
Feste Credits pro gerechneter Wu vergeben. Mehr (schneller) gerechnet = mehr Credits. Ich ärgere mich immer wenn die Credits von einem anderen lahmen Rechner "in den Keller gezogen" werden. Bei E@H mit festem Creditsystem spielen Optimierungen keinerlei Rolle mehr.

scsimodo:
Ich habe jetzt zwar noch keine S5-WU von EAH gerechnet, aber was ich bisher so gesehen habe bekommen auch Durchschnitts-CPUs rund 20 Credits/h. Das geht doch wohl ein bisschen über das Ziel hinaus. Eine CPU dieser Kategorie macht ca. 8-10 Credits pro Stunde mit dem Standard-Boinc-CC (unter WIndows). Irgendwo in diesem Rahmen sollte es auch bleiben.
Ich benutze auch den Crunch3r-Client, weil ich die optimierte S4-Version von Einstein benutzt habe (und ansonsten die eh schon mickrigen Credits noch weiter in den Keller gezogen hätte) und weil er ein "return results immediately" eingebaut hat. In Projekten mit Quorum ist das nicht so das Problem, da wird man automatisch "eingebremst", bei Rosetta und QMC (sofern es mal Credits gibt) sind die claimed credits schon annähernd unanständig. Creditgeil hin oder her, da hört der Spaß dann auf.
Ein vernünftiges Maß an Credits ist völlig ok, die Boinc-Benchmarks sind ohnehin "broken by design".
Die Länge der WU sollte bei der Creditvergabe eine Rolle spielen. Für eine 10h-WU will ich auch 10 mal soviele Credits wie für eine 1h-WU. Was allerdings keine Rolle spielen sollte ist der Benchmarkwert. Eine langsame CPU, die 10h läuft sollte genauso behandelt werden, wie eine schnelle CPU, die 10h läuft. Die schnelle CPU erledigt zwar mehr Arbeit, beide arbeiten aber, kosten Strom und manchmal auch Nerven.
Sinnvoll wären auch Bonuspunkte für den Speicher/HD-Platz den man bereitstellt, die "Verfügbarkeit" (Gelegenheitscruncher oder 24x7). Ich glaube WCG macht sowas mit dem UD-Client. Die Credits steigern könnte man dann ja mit "Zusatzpunkten" für 1 CPU-Tag/Woche/Monat/Jahr. Jeder wäre dann selbst für die Steigerung seiner Punkte verantwortlich und muss nicht auf die "Gnade" der Mitcruncher hoffen.
Eine 1 WU - 1 Credit-Lösung ist Quatsch wenn sie nicht gleich gross sind. Im Zweifel werden die Creditgeier nur Projekte mit kurzen WUs berechnen oder längere WUs abbrechen, damit man nur die kurzen erwischt.
Wenn sich die Boinc- und Projektverantwortlichen mal zusammen setzen würden und diese Probleme besprechen und evtl. Lösungen erarbeiten, dann haben die meine volle Unterstützung. Jede Taskforce (besonders bei Rosetta und QMC) macht eigentlich nicht so richtig Freude, weil ja eh (fast) jeder mit optimierten Clients "bescheisst". Vielleicht bringt ein neues Creditsystem auch mal wieder den eigentlichen Sinn des DC zu Vorschein: Die Wissenschaft an sich UND Wettkämpfe mit fairen und vergleichbaren Ergebnissen.

Chipkiller:
Wenn Projekte dem Trend den Wir zukuenftig staerker gegensteuern werden verlieren sie viele User!
Mit meinen kleinen PC muß ich doch zusehen, wie ich mithalten kann. Also läuft der nur dort, wo es genug abzustauben gibt.
Die wissentschaftliche Seite bei einen Projekt interessiert doch die wenigsten. Es sind doch fast alle auf Credits aus...
Für mich zählen Credits. Wenngleich ich davon nichts habe, außer einen Ansporn noch besser zu sein wenn mich wieder jemand überholt. Credits hin Credits her, SetiClassic war das non plus ultra. 1 Wu = 1 Punkt. Nicht solcher Schnick-Schnack wie jetzt.

andy:
Ich find das system mit nicht aussagekräftigen Benchmarks auszurechnen wieviel credits du zu bekommen hast, nicht passend.
Um credits mach ich mir keine Gedanken... ob es da ein Projekt gibt, dass mehr Credits vergibt ist mir egal. Das credit system an sich ist genial um ganz normale benutzer anzuspornen. Aber vielleicht setzen sich ja alle projektleiter mal an nen runden tisch und tüfteln ein neues credit-system aus.

Miko:
In Sachen Credits bin ich schon lange für einen "grünen Tisch" an den sich alle Projektbetreiber zusammen setzen (...eine Projektadmin-Konferenz) und eine gemeinsame Linie beschliessen sollten. Sie könnten z.B. einen Umrechnungsfaktor bestimmen der die verschiedenen WU's aufeinander abstimmt und kein Projekt und keinen User-PC benachteiligt.
Das soll nur dem Gedanken des gemeinsamen Erfolges dienen und auf keinen Fall ein Instrument sein/werden einige Projekte in ihren Freiheiten einzuschränken! Aber fast ganz ohne Regeln heist anders gesagt auch fast Anarchie... und das bringt in einer Gemeinschaft absolut nichts!
Die Creditstatistiken werden utopisch hoch werden und keinen Bezug zur abgelieferten Leistung haben!
Grade die Gerechtigkeit, das gleich behandelt werden find ich beim VR sehr wichtig! Darf es denn da sein das jemand der viel Geld hat mehr Credits bekommt wie jemand der einen alten PC benutzen muss? Wäre es da nicht gerechter und vor allem einfacher die Credits einfach nach der Uptime des PCs zu verteilen? Alle Credits löschen und dann jedem PC für 60 Min. Laufzeit mit BOINC 1 Credit geben...
Das ist etwas an den Haaren herbeigezogen, aber im Grunde ist was dran.

Athlonheizer:
Daran das selbst manche Projekte cheaten ist schon was dran. Seti Classic war genial 1 WU = 1 Credit! Bevor man darüber nachdenkt wieviel credit es pro WU gibt sollte man erst mal Regeln das bei allen Projekten die WUs gleich groß sind (download) und das deren Berechnungszeit annähernd gleich lang ist. Seti enhanced hats bei mir verschissen. Erst immer etwa 20 Credits/WU dann auf einmal die WUs zich mal so groß und Credits gabs dann nur noch etwa8-12/WU. CPDN genauso. Was soll ich mit ner WU bei der es auf meinem guten rechner heißt 1416std. Ich will sehen was geht und nicht ein halbes Jahr drauf warten müssen.


Forum Science and Research Hessen
(http://www.sar-hessen.de/forum/viewtopi ... =4970#4970)

Wegen Wartungsarbeiten geschlossen


µFluids
(http://www.ufluids.net/forum_thread.php?id=336)

keine Resonanz!


BOINC@Heidelberg
(http://www.boinc-team.de/portal/showtop ... eadid=1095)

tomcat:
"Trickles für alle!" Wer den schnelleren Rechner hat, schafft einfach in derselben Zeit mehr Trickles wie andere, aber das ist dann auch gerecht und keiner kriegt zu wenig, weil der blöde Benchmark bei dem einen besser funktioniert als beim anderen. Ich sehe zwei Hauptziele: Erstens sollten die Credits pro Zeiteinheit und Rechenleitung zwischen den Projekten gleich sein. d.h. mit gleichem Rechner und BS bekomme ich bei LHC, PG, Predictor, climate... gleiche Credits für gleiche Rechenzeit. Hier müssten einerseits sich die Projekte untereinander auf einen Modus bzw. Creditlevel einigen und andererseits dies technisch entsprechend umsetzen. Zweitens sollten die Credits pro Zeit und Leistung unabhängig von Prozessor und Betriebssystem sein. Das System der Trickles bei climate ist gut. Allerdings kann man das IMHO nicht so einfach auf andere Projekte übertragen mit wechselnden Rechenanforderungen bei den WU's. Die Herausforderung dürfte sein, entsprechende Einheiten für andere Projekte zu finden, das entsprechend einzuteilen und mit anderen Projekten vergleichbar zu machen.Könnte man ja gewissermassen eine Art Referenzdesign definieren? Es wird von BOINC ein oder mehrere Rechner definiert, auf denen ein paar Test-WU's bzw. Trickles laufen gelassen und der Zeitaufwand und damit die Credits bestimmt werden.
Allerdings hat man auch bei den trickles eventuell Ungerechtigkeiten. Denn hier hängt die Geschwindigkeit der Bearbeitung auch an der Qualität der Anwendung. Die Dauer für ein trickle wird nicht nur über die Rechenleistung sondern auch über die Qualität der Applikation bzw. des Compilers mit der sie erstellt wurde, bestimmt. Wenn also die besonderen Eigenschaften eines Prozessors z.B. AMD beim Compilieren berücksichtigt wurden, für einen anderen z.B. Intel nicht, läuft die Applikation schneller d.h. der AMD kann mehr trickles bei theoretisch gleicher Leistung pro Zeit schaffen. Konkret benötigen z.B. meine Mac's mit PowerPC für trickles mehr Zeit als ein "vergleichbarer" Intel unter win oder linux. Wenn man optimierte Anwendungen laufen läßt, ist das eher umgekehrt. Aber trotzdem ist das System mit trickles einfacher und m.E. besser. Es wäre halt dann nur wünschenswert, das die einzelnen Projekte möglichst ihre Applikationen optimal compilieren. - was jedoch auch bei allen anderen Abrechnungssystemen z.B. dem Benchmark-definiertem der Fall ist. (allein um möglichst viele WU's bzw. trickles berechnet zu bekommen)

Cori:
Es gibt ja nicht nur die Schwierigkeit, die Projekte untereinander creditmässig "anzugleichen", sondern auch innerhalb eines einzigen Projektes die Unterschiede der einzelnen Betriebssysteme und Prozessoren auszumerzen. Der momentane Benchmark nervt jedenfalls extrem! Ein Grund, warum die "optimierten" BOINC Clients so erfolgreich wurden (auch ohne optimierte Projekt-Anwendung), ist ja z.B. die Tatsache, dass Linux schlechter "bencht" als Windoof, Intel schlechter als AMD usw. Sogar die Relation zwischen Hyperthreading und Single-CPUs ist nicht korrekt... Also da gibt es in meinen Augen nur den Weg über Trickles. Um die unterschiedlichen Rechenzeiten für die WUs verschiedener Projekte zu berücksichtigen, müsste man eine Art "Umrechnungssystem" finden, das z.B. kurze Wus von HC mit x Prozent einer Referenz-WU von CPDN vergütet oder sowas in der Art, quasi ein "WU Duration Correction Factor", der die unterschiedlichen WU-Längen ausgleicht. EDIT: ich überleg grad, wie man die "theoretischen" Unterschiede in den WU-Längen berechnen sollte. Wie lange ein Rechner nachher wirklich pro WU braucht, spielt ja z.B. bei CPDN keine Rolle, denn der eine erhält sein nächstes Trickle halt früher als der andere vergütet. Eigentlich kann man nur alle Projekte auf ein und demselben Rechner laufen lassen und dann die Relationen zwischen den Projekten danach ausrechnen. Wohl gemerkt, die tatsächlich benötigte Zeit darf dabei keine Rolle spielen, es geht nur darum, herauszufinden, dass z.B. HashClash 0,005% einer CPDN-WU "entspricht". (Die Zahl ist rein fiktiv... ) Danach könnte ein HC-Trickle eben 0,005% eines CPDN-Trickles "wert" sein usw. Ausserdem wäre damit Cheating auch nicht mehr möglich, denn das "Trickle-Umrechnungssystem" würde ja von der BOINC-/Projektseite aus bestimmt! Userseitig kann sowas ja nicht beeinflusst werden.


QMC@Home
(http://qah.uni-muenster.de/forum_thread.php?id=208)

Norman RKN:
Gleiche credits für gleiche arbeit. der eine ist halt früher fertig als der andere. der eine hat nen dicken modernen rechner und der andere halt noch einen älteren. Einer kann optimierungen nutzen der andere leider nicht. Dennoch sollte gleiche Rechenleistung mit gleichen Credits vergolten werden. Soll heissen dass alle boincprojekte pro stunde rechenleistung einheitlich credits verteilen sollten!

wolmic:
Beispiel: Einige Rechner haben hier mehr als 1000 Credits je langer WU geclaimt. Ich hatte auch lange WU's, bekam aber nur 400 Credits. Daraufhin habe ich mir die WUs 'mal angeschaut: Ähnliche WUs wie meine, ähnliche CPU, ähnliche Zeit gerechnet. Dort gab es 1000 Credits, bei mir 400... Die Lösung, die sie bei Einstein gefunden haben, gefällt mir gut. Es gibt für jede WU eine vorher festgesetzte Credit-Anzahl; gleiche Arbeit, gleicher Lohn. Siehe auch die Clima-Projekte. Das läßt sich zwar nicht überall so durchführen (bei LHC oder RCN nicht möglich, weil sich die Rechenzeit erst bei der Berechnung ergibt), aber wo es möglich ist, sollte man es schon so handhaben. Und selbstverständlich sollten alle Projekte grundsätzlich die selbe Anzahl Credits je Rechenleistung oder gerechneter Stunde.

Filehunter:
Verwendung manipulierter Clients (einprogrammierte Multiplikatoren für die Benchmarks o.ä.) = absolut intolerabel, sofortiger Ausschluß der betreffenden User; Einsatz (prozessor-)optimierter Clients für nichtoptimierte Anwendungen vielleicht nicht die feine englische Art, aber noch tolerabel (Belohnung für Informiertsein und Talent, diese Clients zum Laufen zu bringen; indirekter Druck auf die Projektentwickler, doch bitte schön ihre Anwendungen effizienter zu programmieren, ...)

Ananas:
- Credits sollten nicht nur nach Gleitkommaleistung vergeben werden. Integerleistung, Hauptspeicher, Plattenplatz, uebermaessiger Traffic, auch das sind Faktoren, die in Extremfaellen durchaus zu veraenderten (i.e. hoeheren) Bewertungen fuehren duerfen.
- Gleitkomma ist nicht gleich Gleitkomma. Akos seine Albert-Clients haben meine CPUs um 5° waermer werden lassen als der Standard-Client, liefen deutlich schneller, haetten aber nach Zeit*Benchmark weniger Credits pro Result ergeben. Viele (mich eingeschlossen) haben das mit Kalibrierung kompensiert. Manche haben die Kalibrierung uebertrieben oder fuer Projekte eingesetzt, die gar keinen optimierten Client haben. Einen solchen Kalibrierungsfaktor projektseitig in Abhaengigkeit vom CPU-Typ vorzugeben, wuerde viele unnoetige Reibereien ersparen.
- Projekte mit hoeherem Absturzrisiko (e.g. CPDN) koennen durchaus nicht linear mehr Credits vergeben, je laenger das Modell laeuft, also anfangs einen eher niedrigen Wert, je laenger das Modell laeuft, hoehere Werte. Die Modelle kosten echt Nerven, das ist m.E. auch ein wertbestimmender Faktor. Nach 100 Trickles ein Modell zu verlieren, ist ziemlich schlimm und kann einen DC-Junkie schon an den Rand eines Nervenzusammenbruchs bringen oder in Depressionen stuerzen, die im Alkoholismus enden
- bei Projekten mit konstanter oder zumindest einigermassen konstanter fpops-Leistung wie Einstein S5 ist "prepaid" eine ziemlich gute Sache, die Loesung gefaellt mir recht gut. Kleinere Schwankungen gleicht die Menge aus.
Die Projekte selbst sollten aber grundsaetzlich die Credits-Hoheit behalten. Wenn ein Projekt sich fuer diese oder jene Methode entscheidet oder auch fuer ein Bonussystem, so sollte das deren Sache sein.
Um gravierende Unterschiede zu kompensieren, koennte ich mir einen Projekt-Korrekturfaktor vorstellen, der bei projektuebergreifenden Statistiken beruecksichtigt wird. Das waere dann nicht mehr Projektsache sondern koennte von Leuten wie Willy, KWSN, Synergy usw. festgelegt werden.
Damit waeren Wissenschaft und User-Wettbewerb halbwegs getrennt und man koennte die Projektleute das machen lassen, was sie eigentlich machen sollen/wollen.
Nachtrag : Ich habe mir mal die Top-Hosts bei Rosetta angesehen, von den 50 RAC-staerksten Hosts dort sind 40 Cheater, 9 davon (Team Maas Family) mit manuell manipuliertem Phantasie-Benchmark, der Rest mit einem gepatchten oder selbstgebauten BOINC-Client, der den Benchmark etwa um Faktor 4 anhebt. Letzteres koennte auch ein BOINCStudio sein, bei dem die Kennung und Kalibrierungsausgaben ueberschrieben wurde, so dass man es nicht als BOINCStudio identifizieren kann. (Versions-String = 5.5.0, die Version gab es nur unter Linux)
Sowas schreckt mich schon etwas ab, ich crunche zum Teil auch fuer Credits, sonst wuerden Projekte, von denen ich recht wenig verstehe, keine Rechenzeit abbekommen und ich koennte im Winter nicht mit CPUs heizen.
Das bedeutet, sobald die 2 Wochen, fuer die Rosetta mehr Leistung angefordert hat, vorbei sind, bin ich dort erstmal wieder raus, bis die ein besseres Credit-System gefunden haben.
Fuer Projekte mit einem 1er-Quorum ist es also besonders wichtig, ein Mass fuer die Credits zu finden, das ueberhaupt nicht auf dem Benchmark sondern nur auf der abgelieferten Arbeit basiert.
p.s.: ich weiss inzwischen, was 5.5.0 fuer eine Client-Version ist - den voellig ueberhoehten Benchmark auch bei Projekten ohne optimierte Projekt-Clients anzusetzen war kein Meisterstueck
Die Einstein-Loesung finde ich auch ziemlich gut. Selbst wenn mal eine WU im Verhaeltnis Zeit/Credits etwas daneben liegt, gleicht sich das nach ein paar WUs im Schnitt wieder aus.
Ausserdem schluckt es vermutlich weniger Rechenzeit, wenn man nicht staendig in die BOINC-API huepfen muss, um dort die hinzugekommenen FpOps fuer einen Schleifendurchlauf oder Funktionsaufruf zu melden.
Zaehlt man bei sehr variablen Laufzeiten nur die WUs, dann besteht das Risiko, dass manche Leute die langen WUs verwerfen und gar nicht rechnen sondern sich die Rosinen 'rauspicken.
Zum Beispiel bei SZTAKI sind die eigentlichen Rosinen fachlich zwar eher die langen WUs (bessere Chance auf Treffer), nach WU-Counter aber doch eher die kurzen.

Rebirther:
Die beste Möglichkeit, um allen aus den Weg zu gehen ist, wenn man jede WU=1 zählt:
1. Benchmarkunabhängig, cheaten unmöglich, Benchmark kann man dann auch weglassen
2. langsamere Computer schaffen auch weniger und werden nicht mit der gleichen Menge wie die schnelleren PCs belohnt
3. man sieht, was man überall an Arbeit geschafft hat
4. die Statsseiten können dann wenigstens noch die Zahlen verwalten
5. man kann bei den meisten Projekten dann auf Quorum 1 gehen, spart Zeit und die Ergebnisse sind auch schneller vorhanden
Dann müßten die Projekte das so regeln, das nur optimierte Clients wie z.B. Simap beim Abfragen neuer WUs mit downgeloaded werden. Und jeder erhält mal kurze oder lange WUs bei einem Projekt, mich interessiert einfach viel mehr, was ich geschafft habe und nicht Zahlen in die Millionen oder größer.
Oder halt so regeln wie bei Einstein, auch ne Möglichkeit und ich finde die Vergabe dort fair.

madmaxventi:
ein boinc rechner der z.b. als referenz dasteht soll eine wu rechnen, den wert den er zum berechnen brauchte dividert durch den bench (integer), sollte die referenz zahl ergeben nachdem jeder rechner, egal welches BS und/oder chip verwendet wird, gleichbleiben.
somit besteht ein ref wert der mit der verrichteten cpu arbeit in sek. multipliziert wird in die credit aufgerechnet wird.
wie nun das auf alle boinc projekte zu bewerkstelligen wär, ich bin überfragt.
nur es steht fest:
ein benchmark wär überflüssig
schummeln nicht mehr möglich
optimierte clients die auf rechenzeit sich auswirken geben mehr credits indem mehr wu's geschafft werden.


Rechenkraft.Net
(http://www.rechenkraft.net/phpBB/viewto ... 83a1#63860)

Michael H.W. Weber:
Ganz ehrlich: Für mich persönlich sind die Credits eher sekundär. Allerdings wäre ein DC projektübergreifend einheitliches Creditsystem auch im Sinne unseres Vereins wünschenswert, einfach um unsere Gesamtleistung realistischer im Vergleich zu anderen einschätzen zu können. Das beschränkt sich übrigens keineswegs nur auf BOINC.
Ich finde, dass der Benchmark dennoch in die Creditvergabe verrechnet werden sollte und schließe mich ansonsten scsimodos Ideen an.
Naja, ich bin schon der Ansicht, dass die Credits proportional zur abgelieferten Rechenleistung vergeben werden sollten. Wie man diese nun am Besten erfasst, wäre zu überlegen. Die Architektur der CPU und damit der Benchmark spielen da durchaus eine Rolle. Zusätzlich sollte man in der Tat - wie von scsimodo vorgeschlagen - den RAM-Ausbau einbeziehen. Ob die Netzwerkfähigkeiten, abgesehen vielleicht von der Unterscheidung zwischen offline und online Maschinen, ein Gewicht erhalten sollten, würde ich verneinen.
Ich finde den Ansatz von Folding@home bislang am Besten. Eine Referenz-WU wird auf der Benutzer-Maschine gebenchmarkt und dann werden die zu vergebenden Credits proportional zu Leistung einer Referenzmaschine des Projektbetreibers vergütet.

scsimodo:
FLOP-Counting mag wohl für das ein oder andere Projekt (mehr schlecht als recht) funktionieren, ist aber keine allgemein brauchbare Lösung.
Warum nicht die Rechenzeit an sich als Maßstab hernehmen? Ein 1GHZ-Rechner benötigt genausoviel Strom, Wartung und Nerven wie ein 3 GHz-Bolide. Klar, er rechnet weniger aber was solls? Für die Credits kann man sich eh nichts kaufen.
Wo ist die "Honorierung" der Ressourcen, die ich zur Verfügung stelle? Gebe ich viel RAM frei für die Anwendung bekomme ich bisher genauso viel Credits wie wenn ich mit dem RAM geize? Mit viel RAM kann ich aber "fettere" WU berechnen. Analoges gilt für HD-Platz (eher unwichtig) oder Leitungsbandbreite. Dazu müsste BOINC aber erlauben meine "WU-Größe" einzustellen, was es bis heute nicht kann. (zumindest nicht ohne AUfwand seitens der Projektbetreiber)
Wo wird mit eingerechnet ob ich Gelegenheitscruncher bin oder meine Maschinen 24x7 laufen lasse? Das ist sehr wohl ein guter Grund für erhöhte Credits.
Mein Vorschlag wäre:
Credits abhängig von Rechenzeit und nicht von Benchmarks. die Benchmarks sind suboptimal und sagen rein gar nichts aus. "Zusatzcredits" für erhöhte Bereitstellung von Ressourcen (HD, RAM, Leitung). Sowas könnte man evtl. als Multiplikator einbauen. Also z.B. x Credits pro Rechenstunde, wer mehr Speicher bereitstellt bekommt dann halt 1,2 mal soviel (nur um ein paar Hausnummern zu nennen). Interessant wären auch Zusatzpunkte z.B. wenn man 1 Rechenwoche, -Monat, -Jahr für ein Projekt hat, oder auch für einzelne Rechner.
Warum nicht auch Extra-Credits für Top-Results (z.B. bei Rosetta)? Oder ein Zuckerl, wenn man z.B. bei Einstein für den S4-Lauf mindestens x Results berechnet hat.
Wo ist im Credit-System die Möglichkeit meine Punkte bei einem Teamwechsel komplett zum neuen Team mitzunehmen? Nicht vorhanden, schlicht und ergreifend. Nur CPDN kann das anscheinend.
Meine Vorschläge sind sicherlich nicht "belastbar", aber so in etwa würde ich mir ein Credit-System vorstellen. Dazu müsste aber auch das ganze BOINC-Framework geändert werden. Dass das einer kompletten Überarbeitung bedarf ist so oder so ein ganz anderes Thema..
Das bisherige System ist IMHO eher ein Ärgernis, die Foren sind voll von Fragen und Beschwerden. Oft genug wird noch nicht mal geschnallt, was es mit den Credits überhaupt auf sich hat. Ein Armutszeugnis, wie ich finde.
Aber egal wie man es macht, irgendwer fühlt sich immer übervorteilt. Im Zweifel sollte ein System gefunden werden, dass für den User da ist, Spaß machen soll und ihn anspornt. Vielleicht sind dann auch TFs wieder mal spannend und aussagekräftig. Und vielleicht haben bei einer gerechten und projektübergreifend identischen Creditvergabe auch mal Projekte eine Chance, die ansonsten nicht gerechnet werden, weil es zuwenig Credits gibt.
Eine Referenzmaschine für alle Projekte!
Eine projektspetifische Benchmark in Form einer Referenz-WU
Die Referenz-WU müsste aber sorgfältig ausgewählt werden sprich: repräsentativ sein. FLOPS und MIPS sollten so verteilt sein wie es in der großen WU auch ist, Vor und Nachbrechnungen sollten analog viel Zeit brauchen etc. pp.

aalerich:
Eine hochgezüchtete Dualcoremaschine bringt mehr Nutzen für die Wissenschaft als ein P II und daran muß sich das Kreditsystem ausrichten.
Die Ressourcen sind so eine Sache; in der Regel dürfte es schwierig werden, dabei ein "gerechtes" System zu finden. Beim Speicher beispielsweise: Kann ich mit mehr Speicher wissenschaftlich wichtigere Berechnungen machen als mit wenig Speicher...? Oder die Netzanbindung, ist die nicht ziemlich egal? Interessant ist doch nur, wie schnell ich Ergebnisse zurücksende und das hängt doch hauptsächlich an Rechenleistung und Rechenzeit.
Die Punktemitnahme beim Teamwechsel sollte so bleiben, wie sie ist. Beim (Non-BOINC) F@H macht man das genauso mit der Begründung, sonst wäre die Gefahr da, daß leistungsstarke Einzelkämpfer abgeworben werden und ein Team von einem Tag auf den anderen im Keller hockt während ein anderes aus eben jenem an die Spitze schießt.
Das Hauptproblem ist meiner Meinung nach, daß mit dem BOINC-System unzählige völlig verschiedene Projekte vergleichbar gemacht werden sollen. Das kann eigentlich nur in die Hose gehen; genau das ist es aber, was den Reiz ausmacht... Wenn Einsteinpunkte nur mit Einsteinpunkten verglichen werden ist es uninteressant, daß es dort für die gleiche Arbeit mehr Punkte gibt als bei anderen Projekten.
Lösen läßt sich das Problem meiner Meinung nach nicht. F@H arbeitet mit Referenz-WUs, die gebenchmarkt werden und alle WUs dieser Art bringen dann die gleiche Punktzahl. Ist aber auch problematisch, weil verschiedene Prozessoren besser oder schlechter mit der gleichen WU arbeiten...
Kurz: Das System ist schlecht, alle anderen Ideen sind aber noch schlechter, so sehe ich das.

Sänger:
Leistung des Rechners x Zeit = Punkte
Um handhabbare Zahlen zu bekommen meinetwegen noch mit einem Faktor versehen (1/7820000 oder so).
Die Leistung des Rechners wird mit einer Benchmark berechnet, und dies ist bei BOINC leider nie ganz ausgegoren gewesen. Und es war offensichtlich sehr leicht zu manipulieren (s. "optimierte" Clients).
Die CPU-Zeit ist afaik recht gut erfasst, zumindest läuft der Zähler bei mir schneller, wenn er sonst nix tut, als wenn er andere Programme am Laufen hat.
Der Ansatz mit den vorherbestimmten Credits per WU ist auch ein feiner, aber er funktioniert nur, wenn der Berechnungsaufwand vorher gut bekannt ist (läuft bei CPDN und Folding). Wenn dem nicht so ist, insbesondere, wenn wie bei LHC der Abbruch der WU wegen Kollision des Teilchens mit der Außenwand plötzlich abgebrochen werden muß, haut das nicht mehr hin.
Bei Folding gab es sogar mal Bonuspunkte für WUs die besonders speicherintensiv oder groß oder sonstwie besonders aufwendig waren.
Meine Meinung (für BOINC):
Benchmark lassen, "optimierte" Clients nicht zulassen.
Wie das technisch gehen kann, weiß ich nicht, denn quelloffen sollte es schon bleiben, und somit ist eine einzelne Manipulation nicht ausgeschlossen. Ich denke aber, das es gegen koordiniertes Rumpfuschen Abwehrmechanismen geben könnte.
Da die Projekte ja grundlegend verschieden arbeiten:
Klare Kenntnisse über die Leistungsanforderungen der WU: Prädestination!
Unklare Verhältnisse: Benchmark x Zeit