[Sammelthread] F@H Quatschthre(a)d

[Picar66]

wenn nicht untersagt wäre würde ich sagen in den Foren von anderen community projekten stöbern und dort schreiben wie reibungslos F@H funktioniert.
So wie mir es bei World community grid ging, ging es anderen auch, Nase gestrichen voll von dem schlechten Projekt.
Statt nun Dinge zu fixen werden immer neue Dinge/Projekte gestartet.

Also ab und an so Kommentare zu unzufriedenen Meldungen das es eben auch F@H überhaupt gibt könnte helfen mehr dafür zu begeistern.
Und sei es auch nur anzusprechen das es eben für Medizinische Grundforschung auch ein F@H überhaupt gibt.
Nur so bin ich ja auch dazu gekommen, durch einen Beitrag, denn selber hätte ich F@H wohl eher nicht gefunden.

Beitrag automatisch zusammengeführt: Gestern um 18:19

zu den 18806ich habe ein Win11 System mit eben so einer 13700 mit P- und E Cores.
Win 11 versucht Langläufer Prozesse auf die E-Kerne zu verschieben. die dann unter der Last zu kämpfen haben.
Schon vor einiger zeit bin ich auf https://bitsum.com/ mit dem Prozess Lasso gekommen.
Damit kann man sehr fein steuern (Regelwerk) was wo wie laufen und in welcher Prio laufen darf.
Ja das kostet ein wenig Geld, aber meiner Meinung nach hat sich das gelohnt.
Insb. beim Starten wo alles auf einmal drankommen möchte hakte der Rechner etwas, nun mit der Regelung ist er viel smoother zu benutzen.
Firmenlaptop ächtzte die ersten 10 Min, Arbeit so gut wie nicht möglich, nun smooth, denn das teil hab ich dort auch im Einsatz.
Bin Admin, daher ging das auch auf Firmenrechner.

 

[lipschitzer]

Ne leider nicht mehr die gleichen WUs aktuell sind es die 18247.
Dann liegt es vielleicht einfach an den Kack WUs.

jep, die 18247 nervt mich auch. kann bestätigen um die die 6Mio PPD auf der 3080Ti. die macht meinen urlaubsboost gerade ganz schön zunichte..

Wenn ich mir Abends um 5 denke "ach, eine geht noch", dann kann ich solche WUs überhaupt nicht brauchen.

hehe, kommt mir bekannt vor. beim Wanderfalter hab ich immer Schiss vor einer 9h WU, die ab und an mal reinkommt...bislang aber noch nie abbrechen müssen

 

[Neo52]

Bei mir passiert es in letzter Zeit gerne mal, dass, wenn ich gerade den PC finishen will, der Download beendet ist und er direkt bei 0,0 % steht
Davor war er wenigstens bei 1 oder 2%, aber in letzter Zeit werd ich gerne mit der Nase drauf gestoßen.
...

...bislang aber noch nie abbrechen müssen

...aber pausieren und später oder morgen fortsetzen ist durchaus auch eine Möglichkeit (auch wenn ich die selbst auch sehr ungern nutze).
Man muss nicht immer abbrechen 😉

 

[lipschitzer]

aber pausieren und später oder morgen fortsetzen ist durchaus auch eine Möglichkeit (auch wenn ich die selbst auch sehr ungern nutze).
Man muss nicht immer abbrechen 😉

stimmt schon, QRB ist dann zwar hin, aber der beitrag zumindest abgeliefert. würde ich im zweifel auch machen, versuch aber dennoch immer WUs direkt zu finishen, ist ja für alle Seiten am besten.
zudem könnts auch mit der deadline schwierig werden, wenn man die 9h pausieren muss, um auf mehr ertrag zu warten.

 

[Liesel Weppen]

...aber pausieren und später oder morgen fortsetzen ist durchaus auch eine Möglichkeit (auch wenn ich die selbst auch sehr ungern nutze).

Das (Bonus-)Punktesystem sagt: Nö.

Aus Erfahrung und Schätzung: Wenn ich eine WU mit zusätzlichen 10 Stunden Pause abschließe, kriege ich weniger Punkte als wenn ich die WU droppe und am nächsten Tag eine frische WU in time abschließe, selbst wenn ich dabei berücksichtige, das ich in die abgebrochene WU Rechenzeit für 0 Punkte versenkt habe. Je schneller die verwendete GPU ist, desto extremer dürfte das sogar noch auffallen. (Was ein Abbrechen/Pause ironischerweise unnötiger macht, weil die WUs ja eh weniger lang dauern)

Fazit: Pausieren is nicht, wegwerfen ist effizienter.

Und weils mich jetzt interessiert hat, habe ich Gemini mal eine Frage gestellt:

I'm doing a Folding at home WU where my GPU achieves 4Mio PPD and the WU takes 4h to calculate.

I have to options:
1) I pause the WU for 10h and complete it after the pause. How many total points do i earn?
2) I drop the WU, start another job with the same WU an complete the second WU in 4h.

Up to what percentage can i drop the WU so that 2) still achieves more or equal total points, including the time wasted for the dropped WU and considering the FAH bonus points?

Die Antwort bestätigt meine Beobachtung. Kurz zusammengefasst: Selbst wenn man die WU bei 100% noch wegwirft, kriegt man mit dem zweiten Ansatz insgesamt mehr Punkte.

Spoiler: Volle Antwort

When taking into account the exact execution time wasted at 0 points reward, the Quick Return Bonus (QRB) formula dictates that you can drop the WU at up to 100% completion and it remains mathematically optimal to do so. In fact, the theoretical limit where Option 2 drops below Option 1 is 554.79% completion, which is physically impossible. [1]

Step-by-Step Mathematical Proof

1. Establish the Baseline Points
If your GPU hits 4 Million PPD and a complete WU normally takes 4 hours (\(T_{\text{base}} = 4\)), the maximum possible point value for that job (returned with zero delay) is a fixed constant (\(P_{\text{max}}\)):
\(P_{\text{max}}=\frac{4,000,000\text{\ PPD}\times 4\text{\ hours}}{24\text{\ hours/day}}=666,666.67\text{\ points}\)

2. Option 1: Pausing for 10 Hours
When you pause for 10 hours, your final elapsed processing turnaround time (\(T_{\text{elapsed}}\)) increases from 4 hours to 14 hours.
The FAH QRB formula states that reward points scale down by a factor of \(\sqrt{\frac{T_{\text{base}}}{T_{\text{elapsed}}}}\). Thus, your total points earned under Option 1 is:
\(P_{\text{opt1}}=666,666.67\times \sqrt{\frac{4}{14}}\approx \mathbf{356,348.32}\text{\ points}\)
The overall operational efficiency over those 14 hours drops your net productivity to:
\(\text{Efficiency}_{\text{opt1}}=\frac{356,348.32\text{\ points}}{14\text{\ hours}}\approx 25,453.45\text{\ points/hour}\)

3. Option 2: Dropping at Progress Percentage (\(p\))
Let \(p\) be the completion fraction (\(0 \le p \le 1\)) when you choose to scrap the job.

• Wasted Time: You spent \(4 \times p\) hours processing a job that will yield 0 points.
• New Time: You spend an additional 4 hours completing a completely fresh replacement job cleanly.
• Total Time Invested: \((4 \times p) + 4 = 4(p + 1)\) hours.
• Total Points Earned: Because the new job is finished with zero delay, you earn the full \(P_{\text{max}} = 666,666.67\) points. [1]

Your overall net operational efficiency under Option 2, fully factoring in the zero-point penalty of your wasted time, is:
\(\text{Efficiency}_{\text{opt2}}=\frac{666,666.67\text{\ points}}{4(p+1)\text{\ hours}}\)

4. Finding the Break-Even Percentage (\(p\))
To find up to what completion level you can dump the current unit and still come out ahead, we calculate where Option 2's net efficiency matches or exceeds Option 1's net efficiency:
\(\frac{666,666.67}{4(p+1)}\ge 25,453.45\)
\(4(p+1)\le \frac{666,666.67}{25,453.45}\)
\(4(p+1)\le 26.1918\text{\ hours}\)
\(p+1\le 6.5479\)
\(p\le 5.5479\)
Converting the fraction to a percentage gives \(p \le 554.79\%\).

Conclusion
Because actual progress cannot exceed 100%, you can drop the work unit at 100% completion and a clean reset will still reward you with a higher point density over time than if you chose to pause and resume.
The penalty of losing 4 full hours of computation time is entirely offset by the aggressive, exponential nature of the FAH Quick Return Bonus formula. [1]
To avoid having to make this choice in the future, would you like help setting your client config to use the "Finish" command so it stops pulling new WUs and safely finishes the current one before a break?

Die Gleichungen kriege ich leider nicht vernünftig rauskopiert. Und ich hab das natürlich nicht selbst nachgerechnet um es auf Korrektheit zu prüfen.

Und natürlich sollte man nicht soviele WUs droppen, das man unter 80% Completionrate fällt und den Bonus verliert. Von daher sind mir WUs mit schlechten PPDs aber kurzen Laufzeiten auch gar nicht so ungelegen. Damit baut man dann wenigstens Vorrat auf.

Beitrag automatisch zusammengeführt: Gestern um 21:26

zudem könnts auch mit der deadline schwierig werden, wenn man die 9h pausieren muss, um auf mehr ertrag zu warten.

Die Deadline ist meist zwischen 3 und 5 Tagen... das wird also eher selten ein Problem sein.
Der Timeout (wenn man den überschreitet, krieg man afaik nur noch die Base-Points) ist meist 1-2 Tage... selbst das ist also eher weniger ein Problem.

 

[lipschitzer]

Die Deadline ist meist zwischen 3 und 5 Tagen

gibt viele projekte mit 2 tagen deadline, 1 tag timeout. glaube meine 9h WU gehörte dazu. wenn ich heut nicht fertig werd und es morgen regnet, wärs damit zwangsläufig ein abbruch. ist auch ok und macht sinn, wenn das lab die WU dann nicht mehr gebrauchen kann. aber wäre für so kWh beschränkte falter wie uns (oder vllt auch für zocker, die die graka wieder brauchen) schon sinnvoll, wenn man vorab irgendwie eine maximale rechenmenge oder so parametrieren könnte (falls das überhaupt gpu übergreifend geht), wegen mir auch mit leichter ppd abstrafung, aber dass man zumindest nen einfluss auf die grösse der WUs hat, wenn man weiss, dass man demnächst pausieren muss. der grakatyp scheint das ja bereits zu beeinflussen, dann könnte das ja ein parameter auch. ist aber wahrscheinlich eher ein nischenproblem und kein extra feature wert.

 

[Liesel Weppen]

gibt viele projekte mit 2 tagen deadline, 1 tag timeout. glaube meine 9h WU gehörte dazu. wenn ich heut nicht fertig werd und es morgen regnet, wärs damit zwangsläufig ein abbruch.

Ja, wenns den ganzen nächsten Tag regnet und man deswegen auch nicht weiterlaufen lassen will, dann kanns knapp werden.
Dachte eher an den Fall, das es Abends noch zuviel Akku frisst oder man pausieren will, weil man nichtmal einen Akku hat und dann einfach am nächsten Tag weitermacht.

aber wäre für so kWh beschränkte falter wie uns (oder vllt auch die zocker, die die graka wieder brauchen) schon sinnvoll, wenn man vorab irgendwie eine maximale rechenmenge oder so parametrieren könnte (falls das überhaupt gpu übergreifend geht), wegen mir auch mit leichter ppd abstrafung, aber dass man zumindest nen einfluss auf die grösse der WUs hat, wenn man weiss, dass man demnächst pausieren muss.

Oder wenn man einfach dafür sorgen würde, das die WUs nicht so extrem unterschiedlich sind, weder von Laufzeit noch von den PPD und alleine deswegen schon keiner mehr auf die Idee käme da Cherry-Picking betreiben zu müssen.
Wobei ich aber auch das Problem von den Extremfaltern verstehe, die mit 3x 5090 falten und da eine WU in 20min durchwuppt, aber Upload und Download der neuen WU dann 5 Minuten dauert und die dadurch eben signifikant Punkte "verlieren".

Du kannst aber auch meine Beiträge hier von vor 2-4 Jahren rauskramen, da hab ich schon exzessiv genau darüber gemeckert.

Edit: Ich benutze übrigens sogar hin und wieder den Laptop-Akku dafür. Der hat knapp 0,1kWh und reicht zum Falten ~45 Minuten, dann aber mit reduzierter Leistung (die GPU ist dann auf 50W gedrosselt, statt das sie bis zu 110W im Netzbetrieb nimmt). Da verliert man zwar auch PPD, weil die WU damit ein bisschen länger braucht, aber man kriegt sie eben noch fertig.

Edit2: Ich benutz den Laptopakku sogar um meinen Stromverbrauch zu "strecken". Wie heute z.B. mein Geschirrspüler hat 2 Heizphasen a 20min, da zieht er 2kW. Wenn der Laptop gleichzeitig faltet, steck ich den Laptop in den Heizphasen aus. Er faltet dann auf Akku weiter, ich brauche 150W weniger Strom aus dem Netz. Wenn ich den Laptop wieder einstecke, braucht er etwas mehr weil der Akku wieder lädt. Somit hab ich 2x20 Minuten 150W weniger Netzbezug. Und ausserhalb der Heizphasen etwas höheren Stromverbrauch, aber den kann ich aus PV/Akku decken, weil der dann unter den 600W bleibt.
Ja, ich weiß, das ist in Summe trotzdem verschwindend wenig Leistung, aber mir macht es "Spaß" solche Kleinigkeiten zu min-maxen.

Edit3: Wenn das Wetter mitspielt, könnte ich Threefold.io vielleicht noch überholen, bevor der Winter kommt.

 

[lipschitzer]

Upload und Download der neuen WU dann 5 Minuten dauert und die dadurch eben signifikant Punkte "verlieren".

ach interessant, ich falte gerade mit super schlechtem netz irgendwo in dänemark und war überrascht, dass er während der absurden 20-30min upload parallel schon die nächste WU faltet. vllt ist das ja zufällig ein problem, das zwischenzeitlich gelöst wurde ..wobei der kleinere download ja weiterhin bremst...

Oder wenn man einfach dafür sorgen würde, das die WUs nicht so extrem unterschiedlich sind, weder von Laufzeit noch von den PPD und alleine deswegen schon keiner mehr auf die Idee käme da Cherry-Picking betreiben zu müssen.

würde mich auch interessieren, warum die laufzeiten so extrem unterschiedlich sind und ob das nicht gleicher ginge. das mit den ppd ist soweit ich weiss aber ne graka hardware abhängigkeit und folglich nicht möglich gleichzuziehen. wir hatten hier in den letzten wochen schon festgestellt, dass ein bestimmtes projekt zb auf kleinen grakas unterdurchschnittliche PPD liefert während es auf grossen grakas eines der besten projekte ist. das für mich und @rookbom nervige 18247 zB könnte auf ner größeren/kleineren graka evtl super punkten. wahrscheinlich gibts ne ähnliche begründing mit den laufzeiten. und ich verstehe ja, dass man PPD cherrypicking verhindern will...mir/uns geht es ja nur um die ETA...

 

[Liesel Weppen]

ach interessant, ich falte gerade mit super schlechtem netz irgendwo in dänemark und war überrascht, dass er während der absurden 20-30min upload parallel schon die nächste WU faltet. vllt ist das ja zufällig ein problem, das zwischenzeitlich gelöst wurde

Ja, ist mir neulich auch mal zufällig aufgefallen, das der v8-irgendwas neuerdings die neue WU schon runterlädt, während die fertige WU noch hochlädt. Das ist definitiv mehr oder weniger "neu".

würde mich auch interessieren, warum die laufzeiten so extrem unterschiedlich sind und ob das nicht gleicher ginge. das mit den ppd ist soweit ich weiss aber ne graka hardware abhängigkeit und folglich nicht möglich gleichzuziehen.

Wenn du dir mal deine WUs genauer anguckst, wirst du feststellen, das die sogar auf unterschiedlichen "Cores" laufen.
Die 18247 z.B. auf Core 0x27, 15413 z.B. auf Core 0x24, dann hätte ich z.B. relativ frisch die 12138, die sogar noch auf Core 0x23 läuft. Das alleine sind schon enorme Unterschiede.
Dann kommt auch noch dazu, welche konkrete Rechenoperationen eine WU braucht und wie gut die jeweilige GPU genau diese kann...
Und dann kommt noch AMD VS Nvidia dazu. Nvidia-GPUs laufen mit CUDA. Auf AMD-GPUs wird mit OpenCL gerechnet. Und CUDA ist leider einfach um Welten besser, bzw. die Cores nicht auf OpenCL optimiert.
Meine Nvidia 4060m macht zuverlässig 3,5-5Mio PPD bei ~100W (150W komplett), die RX6900xt in meinem Gaming-PC macht dagegen zwischen 3 und 8Mio PPD je nach WU, aber halt dann bei 250W (300-500W gesamt)... wobei die 8mio PPD echt extrem selten sind. Unterm Strich macht die 6900xt trotz mehr als doppelter Rohleistung kaum mehr PPD als die 4060m. Weil läuft halt mit OpenCL statt CUDA.
Deswegen haben ja auch alle Hardcorefalter hier NV-GPUs. Und selbst da performt halt eine neuere 50xx noch besser als eine "alte" 40xx.

Also "einfach" kann man das definitiv nicht angleichen. Schon gar nicht auch noch über verschiedene GPUs hinweg.

 

[sptn.]

[...] wenn das lab die WU dann nicht mehr gebrauchen kann.

Keine Sorge, abgebrochene oder nicht fertiggestellte WUs gehen wieder an einen Anderen raus. Im kleinen Maß ist das okay, und wird stellen weiße sogar extra gemacht. Es werden vereinzelt erfolgreich fertiggestellte WUs noch mal rausgegeben. Kann dir aber über mein äußerst begrenztes Halbwissen hinaus leider keine sinnvolle Erklärung dafür geben außer, dass damit ein sanity check gemacht werden soll, ob die Berechungen sich decken.

aber wäre für so kWh beschränkte falter wie uns (oder vllt auch für zocker, die die graka wieder brauchen) schon sinnvoll, wenn man vorab irgendwie eine maximale rechenmenge oder so parametrieren könnte (falls das überhaupt gpu übergreifend geht), [...]

[...] ob das nicht gleicher ginge. das mit den ppd ist soweit ich weiss aber ne graka hardware abhängigkeit und folglich nicht möglich gleichzuziehen[]

Das sind Themen die es praktisch seit anbeginn der Zeit gibt. Zusammen mit vielen anderen Themen, wie: WUs im vorraus runterladen und rechnen, wenn man nicht online sein kann und später alles als Paket wieder einreichen. Diese Fragen und Beschwerden kommen immer wieder rein und werden immer wieder abgewiesen mit den entsprechenden Erklärungen.
Einer der Hauptgründe ist, dass es für das ganze Projekt nur EINEN festangellten Entwickler gibt. Es gibt zwar viele Dinge bei denen man Teilnehmen kann und seinen Beitrag leisten, aber nicht für solche Zentralen und existentiellen Dinge. Der Fokus liegt immer auf der Verbesserung und Maximierung der Berechnungsleistung. Zuletzt war es die AMD-HIP integration (auf die wir irgendwie immer noch warten) und davor war es das ARM-enabling für FAH. Parallel wird immer weiter an den Cores geschraubt, dass auch da von Generation zu Generation mehr rauskommt.

Beitrag automatisch zusammengeführt: Heute um 07:03

Control signal 1 heisst idR das das OS den Prozess beenden will.... z.B. getriggert dadurch, das der User den Prozess mit Strg+C beenden will, oder das Betriebssystem runterfahren/neustarten will.

Sind deine Logauszüge "durchgängig"? Also liegen zwischen dem ersten Abbruch und dem Weitermachen wirklich über 4 Stunden?
Dann hat der Rechner vielleicht neugestartet... wegen Updates?

Damit hätte es auch überhaupt nichts mit der WU zu tun.

Es sind 4 Minuten, keine 4 Stunden

Ich noch mal im Detail geschaut, es scheint wirklich so zu sein, als ob es bei ALLEN Systemen der Fall ist. Es sind aber NUR die CPUs, die GPUs laufen easy durch und es ist auch nicht WU-abhängig. Manchmal gibt es über die WUs 3 neue Anläufe, manchmal 5. Manchmal dauert es nur 4 Minuten, manchmal geht es fast lückenlos weiter. Die WUs werden auch fertig, es gibt keine Fails. Da Captain.Ks Hardwarepark ein Mix aus alter und (mittlerweile nicht mehr ganz) brandneuer Hardware ist, schließe ich das als Grund definitv aus. Der Fehler weist auch auf ein OS-Ding hin. Frage mich nur warum so flächendeckend, wärend Andere das gar nicht haben.

 

[lipschitzer]

für das ganze Projekt nur EINEN festangellten Entwickler gibt

krass, das hätte ich nicht gedacht! um so verständlicher, dass diese extrem beschränkte kapa nicht für so spezialfälle verschwendet wird, wenn sich mit Core Optimierungen, die ja für alle greifen, sicher viel mehr Gesamtergebnis rausholen lässt.

 

[sptn.]

Man kann im GIT Projekt von FAH reinschauen und an bestimmten Dingen mithelfen und seine Programmierfähigkeiten einbringen. Keine Ahnung in welchem Umfang das gemacht wird. Aber gerade bei dem Thema Leistungsparametrierung der WUs für die Hardware fallen mir mehrere Probleme ein:

Die Leistungsanforderungen ist so unterschiedlich, dass die Klassifizierung komplex wird. Beispiel: Captain.K hat anfangs mit dem ersten Core2Duo gerechnet, in einem Jahr knapp 1 Mio Punkte geschafft, war etwa 1k Punkte pro WU. das sollte meines Wissens immer noch gehen. Im vgl. zu den größten AMD Brechern praktisch Elektroschrott. Man müsste also alles an CPUs, was gegenwärtig falten kann auflisten und dann nach Leistung klassifizieren. Das geht vermutlich nur darüber, dass man testet, was die effektiv schaffen. Jeden einzelnen Typ. Was passiert aber, wenn jemand mit 2-3-12 Kernen/Threads weniger faltet. Wie ermittelt man dann die Leistung und meldet das dann an den Server zurück, dass der die WU entsprechend anpasst. FAH trackt zwar die verwendeten Betriebsysteme und GPU Hersteller, im Detail wird aber nichts auf den User runtergebrochen, einfach weil das auch ein einormer Rechenaufwand wäre eine Engine dahinter zu bauen, um speziell auf den User zugeschnittene WUs rauszugeben.

Ich kenne dein Problem, weil ich anfangs auch nur mit Laptop CPU gefaltet habe und habe es auch in der der Kategorie "Verbesserungsvorschläge" eingebracht, aber auch die gleiche Antwort bekommen...
Der Ursprung des Projektes ist auch ein Anderer und nicht auf den periodischen Falter ausgerichtet, sondern auf konstante Last.
FAH war ja ganz am Anfang ein Bildschirmschoner für die PCs die einfach permanent an waren und haben eben in der Idle-Zeit ihre Faltdinge gemacht. Sobald man wieder dran war wurde FAH im Hintergrund etwas runtergefahren. Pause war dabei aber nie. Auch Laptops und Mobiles Internet waren damals noch nicht so weit verbreitet, dass das bei FAH relevant gewesen wäre.

 

[lipschitzer]

Der Ursprung des Projektes ist auch ein Anderer und nicht auf den periodischen Falter ausgerichtet, sondern auf konstante Last.

genau das gefühl hatte ich auch und das ist auch ok so für mich. nur schliesst sich hier etwas der kreis zu deiner ursprünglichen frage, ob man vllt in der solar community ein bisschen missionieren könnte. nicht dass es dort nur an der planbarkeit scheitert, wie @Liesel Weppen schon ausführlich begründet hat, aber wäre für solche potentiellen neuen gruppen sicher hilfreich.

FAH war ja ganz am Anfang ein Bildschirmschoner für die PCs die einfach permanent an waren und haben eben in der Idle-Zeit ihre Faltdinge gemacht. Sobald man wieder dran war wurde FAH im Hintergrund etwas runtergefahren. Pause war dabei aber nie. Auch Laptops und Mobiles Internet waren damals noch nicht so weit verbreitet, dass das bei FAH relevant gewesen wäre.

schon interessant für jemanden wie mich, der so spät dazu gestoßen ist, wie das mal alles angefangen hat, bevor die GPU monster ins spiel kamen. und ja, ist schon alles sehr speziell bei mir, wonach sich deshalb auch nichts richten sollte, solang nicht auch viele andere überschneidende probleme hätten.

 

[sptn.]

[...]
schon interessant für jemanden wie mich, der so spät dazu gestoßen ist, wie das mal alles angefangen hat,
[...]

Ja das gibt es noch viele Details. Die ersten WUs waren so klein, dass es sogar x,5 Punkte gab, also 3,5 Credits oder sowas. Kann man sich nicht mehr vorstellen.

 

[rookbom]

Sehr interessant die Einblicke durch eure Diskussion.
Ich war z.B. bis ich das gelesen habe davon ausgegangen für eine WU gibt es die gleiche Punktzahl, egal wie lange ich brauche um sie zu berechnen. Also auf die absolute Zahl gesehen. Beeinflusst natürlich vom Bonus aber nicht von der Zeit.
Als Beispiel zur Verdeutlichung:
WU ergibt insgesamt 1 Mio Punkte wenn am Stück mit Bonus gefaltet wird
0,5 Mio Punkte wenn am Stück ohne Bonus gefaltet wird.
Bisherige/falsche Annahme: 1 Mio Punkte mit Bonus wenn zwischen drin pausiert wird.
Der Faktor zwischen mit und ohne Bonus willkürlich gewählt.

Die PPD für die WU schwanken natürlich je nachdem wieviel ich pausiere.
Aber scheinbar sinken ja auch die absoluten Punkte wenn ich pausiere, so dass die Beispiel WU mit Pause dann nur 0,8 Mio Punkte bringt

Hab ich das richtig verstanden?

 

[Icke]

@rookbom ... ja, die Zeit bestimmt die PPD sehr maßgeblich mit. Je schneller die WU durch ist, desto mehr PPD. Das war glaub, was @Liesel Weppen weiter oben von der KI hat berechnen lassen. Hatte allerdings keine Lust, mir den langen englischen Text zu geben, daher vermute ich nur, dass es die Detailerklärung/Berechnung ist. 🫣.


Ansonsten gibt es mal wieder einen ernsthaften Grund für eine hemmungslose Jubel-Arie: @forenleser0815 hat in nur etwas über sieben Monaten heute schon den zwei Milliarden Milestone weggeknüllt. Dolle Sache, dass Du so schwungvoll drangeblieben bist (der Juli war mal richtig jut ... hast Du PV-Überschuss gehabt, oder was war da der Auslöser für den temporären PPD-Schub?) ... so wird das was mit der medizinischen Weltrettung.

​

... und @lipschitzer hat als mobiler Urlaubsfalter gerade die Fuzzi Top-20 unserer HoF gestürmt. 👍

​

 

[rookbom]

Das mit den PPD hatte ich auch immer schon gedacht, aber das auch die Points für die WU schwanken war mir neu

 

[sptn.]

Sehr interessant die Einblicke durch eure Diskussion.
Ich war z.B. bis ich das gelesen habe davon ausgegangen für eine WU gibt es die gleiche Punktzahl, egal wie lange ich brauche um sie zu berechnen. Also auf die absolute Zahl gesehen. Beeinflusst natürlich vom Bonus aber nicht von der Zeit.
Als Beispiel zur Verdeutlichung:
WU ergibt insgesamt 1 Mio Punkte wenn am Stück mit Bonus gefaltet wird
0,5 Mio Punkte wenn am Stück ohne Bonus gefaltet wird.
Bisherige/falsche Annahme: 1 Mio Punkte mit Bonus wenn zwischen drin pausiert wird.
Der Faktor zwischen mit und ohne Bonus willkürlich gewählt.

Die PPD für die WU schwanken natürlich je nachdem wieviel ich pausiere.
Aber scheinbar sinken ja auch die absoluten Punkte wenn ich pausiere, so dass die Beispiel WU mit Pause dann nur 0,8 Mio Punkte bringt

Hab ich das richtig verstanden?

Jede WU hat ihre Base Credits, die du bekommst wenn du keinen Passkey eingibst. Darüberhinaus bekommst einen Bonus, je schneller du die WU zurückgibst, weil dann der Wissenschaftliche Prozess weniger ausgebremst wird.

Auf der FAH Seite gibt es dazu noch mal eine Erläuterung

 

[Picar66]

Points, stats & passkey

dort ist die Punktevergabe wie folgt beschrieben
final_points = base_points × max(1, sqrt(k × deadline_length / elapsed_time))

deadline_length berechnet sich auf der Dauer für so eine WU auf einem Referenzrechner.
elapsed_time ist vom Erhalt der WU bis finish und eben nicht die Zeit die gerechnet wurde.
Deshalb hat ein pausieren auch so eine enorme Auswirkung auf die Punkte.
k wird je nach Projekt vergeben und sollte im Normalfall 0,75 sein steht da.
base_points kann man an der WU ersehen und soll ebenfalls hergeleitet sein von einem Referenzrechner der so eine WU durchgezogen hat.

Der Referenzrechner wird nicht weiter beschrieben, also die Base_point und deadline_length leiten sich zwar davon ab aber ob die Referenz wechselt von früheren zu späteren Projekten ist unbekannt.

Wenn die WU eine deadline von 4 Tagen hat (96 Stunden) und man die WU nun in 2 Std durchrechnet, dann gibt es mehr Punkte als wenn man diese 2 Std aufteilt in heute 1 Std und morgen auch eine Stunde. Die Pausenzeit zählt mit in der Berechnung.

Zu dieser Basisformen kommt dann noch ein QRB (schnell durchgerechnet Bonus) hinzu wenn man dafür qualifiziert ist (Passkey gesetzt und schon ein wenig gefaltet).
Der genaue Bonus wird nicht erklärt hat aber wieder mit der Zeit vom Bekommen bis Fertig zu tun.
Ob er die Leistungsfähigkeit des Client irgendwie berücksichtigt ist mir nicht bekannt.
Das Punktesystem ist also darauf ausgelegt möglichst schnell das Ergebnis zu bekommen, nicht die Leistung die der Client erbracht hat.
Man hätte das Punktesystem in der Basis oder auch vollständig an der Leistungsfähigkeit des Clients ausrichten können, hat man hier aber nicht.
Das wäre z.B. diese WU braucht x Tflops, eine CPU braucht also x Std eine GPU y Std. egal wie schnell das fertig ist, es wurde eine Leistung von xTflops erbracht, daher gleiche Punkte.
So ein System wäre in gewisser Hinsicht gerechter.

 

[sptn.]

[...]Die Pausenzeit zählt mit in der Berechnung.
[...]

Genau, weil die Zeit zählt, ab wann der Server die WU rausgegeben hat und wann er Sie wiederbekommen hat. Er hätte sie ja auch jemanden vergeben können, der den Job sofort fertigstellt.

[...]
Das Punktesystem ist also darauf ausgelegt möglichst schnell das Ergebnis zu bekommen, nicht die Leistung die der Client erbracht hat.
Man hätte das Punktesystem in der Basis oder auch vollständig an der Leistungsfähigkeit des Clients ausrichten können, hat man hier aber nicht.
Das wäre z.B. diese WU braucht x Tflops, eine CPU braucht also x Std eine GPU y Std. egal wie schnell das fertig ist, es wurde eine Leistung von xTflops erbracht, daher gleiche Punkte.
So ein System wäre in gewisser Hinsicht gerechter.
[...]

Das Problem ist auch bekannt und wird im Discord Server als "Point inflation" genannt. Die Zeit geht irgendwie nicht ganz linear in diese Berechnung ein, das bedeutet je mächtiger die GPU ist, die durch die WUs Pflügt wie ein heißes Messer duch Butter um mehr bekommt sie im vgl. zu schwächerer Hardware. Das potenziert sich dann. Deswegen ist eine 5090 auch der Sweet Spot was PPD/W angeht, einfach weil das Punktesystem die schnellste Simulation begünstigt.

 

[lipschitzer]

@Picar66 nach meinem Verständnis war der zweite Teil deiner Gleichung mit der Wurzel drin, genau der quick return Bonus. und ich fand das eigentlich auch fair, weil das System ja davon abhängt, dass man eine wu schneller zurückliefert, damit die darauffolgende wu vom System angefangen werden kann und die Wissenschaftler aus zeitigeren Ergebnissen mehr Nutzen ziehen als aus späteren. man will also einen Anreiz setzen, mit dem Ergebnis nicht zu trödeln. und richtig der exponentielle Charakter geht insb bei den großen Karten natürlich irgendwann komplett durch und der zugeschriebene Punkte wert besteht eigentlich nur noch aus qrb und kaum noch aus dem base credit.

 

[Picar66]

Ein schneller WU crunsher bekommt automatisch mehr WU pro Tag und damit mehr Punkte.
Ein langsamerer crunsher kann logischerweise pro Tag weniger schaffen.
Aber auf eine WU bezogen ist es ungerecht, denn die Leistung die erbracht wurde ist ja die gleiche, egal ob in 5 min oder in 1Std erledigt.
Das ist der Teil der irgendwie ungerecht ist bei den Punkten. Ich werde es nicht ändern können, aber das wäre meine Meinung dazu.
Ein Punktesystem das auch die Leistung eines Clients würdigt fände ich besser.
Um in der veröffentlichten Formel zu bleiben das Time_elapsed nicht auf reale vergangene Zeit zu beziehen sondern auf benötigte Rechenzeit (egal mit welchen Unterbrechungen).
Natürlich muss so ein computing insgesamt zusehen das Ergebnisse auch flott kommen, aber das tun sie ja mit dem Timeout und Deadline Zeiten schon.
Zu lange Pausen = 0 Punkte.
Und ob bei der Masse an zu berechnenden WU nun nur Std, vergehen oder 2-4 Tage bis zurück dürfte die Wissenschaft nicht wahnsinnig ausbremsen.

 

[lipschitzer]

wenn du es wirklich unabhängig von der rechengeschwindigkeit machen wolltest, dann dürfte der ganze wurzelterm gar nicht enthalten sein, sondern dann gäbe es nur eine feste punkteanzahl pro wu. man macht die Formel aber gezielt komplizierter um ein zeitigeres rückgeben zu belohnen. zwar steckt dieselbe Menge Arbeit darin (auch das ist zu diskutieren, weil ältere grafikkarten mehr Strom/energie brauchen um eine wu zu berechnen als neuere), aber der wert einer wu für die forschenden ist höher, wenn sie zeitiger zurückgegeben ist, weil sie dann (vereinfacht gesprochen) schneller die nächste wu starten können (edit: so eine Simulation besteht ja aus vielen sequenziellen und parallelen WUs, wobei die sequentiellen vom Ergebnis der vorherigen abhängen) und insgesamt besser mit ihrer Forschung vorankommen. denn sie haben ja in ihren Projekten auch einen festen zeitrahmen und müssen gut überlegen welche Komplexität einer Simulation in ihrem zeitramen realistisch ist.