Dicke WUs, was sind die rechenintensivsten?

[bull]

Na super, hab so ne 160er WU auf mein neues Centrino-Schlepptop gespült bekommen, braucht rund 40min pro Durchgang. Kann man dem Ding nicht irgendwie sagen daß es allergnädigst etwas kleinere runterladen soll - zum Wohle des Projekts?

[Patrick Keller]

Wieso zum Wohle des Projektes ? Jede WU muss gerechnet werden. Selbst wenn die etwas später wiedeer kommt ist das nicht schlimm. Einfach durchrechnen und auf die Punkte freuen

[willmannand]

Jede WU muss gerechnet werden.

Da muß ich Keller recht geben. Jedes Ergebnis einer WU ist nützlich, egal wie groß die WU ist.

Zudem kannst du dich noch freuen: auf meinen Rechner (Athlon 1,4 GHz) dauert die Berechnung eines Prozentpunktes (160'er WU) mindestens 67 min. Wenn ich dazu noch den Rechner nutze, dauert es etwa 80 bis 90 min pro Prozentpunkt.

[SpeedKing]

Wieso zum Wohle des Projektes ? Jede WU muss gerechnet werden.

Eben. Und weil die nächste WU-Generation von der jetzigen abhängt, sollten schnelle Rechner große WUs und langsame Rechner kleine WUs rechnen. Zum Wohle des Projekts.

Selbst wenn die etwas später wiedeer kommt ist das nicht schlimm. Einfach durchrechnen und auf die Punkte freuen

Das ist aber nur zum Wohle des Teilnehmers.

[Patrick Keller]

Aber wo ist das Problem ? Solange der Rechner die WU in der Deadline abliefern kann (und das kann er mit nahezu Sicherheit) tut er dem Projekt was gutes, weil bis DAHIN wird die WU niemand anderem gegeben.
Sollte man die WU jetzt löschen, wird die WU trotzdem niemandem ausgegeben. Also: Einfach rechnen und glücklich sein
SpeedKing: Es gibt nicht nur eine nächste Generation: Aus einer Generation (im schlechtesten Fall Generation 0) gehen mehrere Generationen hervor, die aber eigentlich nur Blindgänger sind, vorher weiß man das allerdings nicht. Nach der ersten Generationen haben wir zb 5 zweite Generationen, von der jeweils eine zu 2 dritten Generationen führt, wo wir schon bei 10 dritten Generationen sind. Ich hoffe du verstehst was ich meine

[SpeedKing]

Aber wo ist das Problem ? Solange der Rechner die WU in der Deadline abliefern kann (und das kann er mit nahezu Sicherheit) tut er dem Projekt was gutes, weil bis DAHIN wird die WU niemand anderem gegeben.
Sollte man die WU jetzt löschen, wird die WU trotzdem niemandem ausgegeben. Also: Einfach rechnen und glücklich sein

Löschen bringt nix, man müßte im Client vor dem Download der WU angeben können, wie schnell der Rechner ist (also nicht nur den Benchmarkwert, sondern auch die Angabe, wie lange der Rechner durchschnittlich pro Tag läuft). Dann könnte jeder Rechner eine passende WU bekommen und die aktuelle WU-Generation könnte deutlich vor ihrer Deadline duchgerechnet sein - das Projekt würde schneller vorwärts kommen.
Aber dieses Problem ist ja bekannt und angeblich wird daran gearbeitet.
Wobei - langfristig bringt es wahrscheinlich doch nichts, weil ja jeder ständig neue WUs bekommt, egal aus welcher Generation oder welchem Seitenzweig die jetzt stammen. Das gesamte Projekt wird höchstwahrscheinlich genauso schnell durchgerechnet.

[Michael H.W. Weber]

@bull: Nein das kann man leider (noch) nicht, obwohl der anfängliche Benchmark genau dafür bestimmt ist, d.h. Rechner mit geringerer Benchmark-Performance sollen irgendwann einmal kleinere WUs bekommen. In der Praxis ist das leider noch immer nicht umgesetzt, obwohl dieses "feature" schon seit über einem Jahr besteht. Grund für die fehlende Umsetzung ist vor allem das, was SpeedKing erklärt hat: Es spielt nicht nur die Rechenpower eine Rolle, sondern auch die Zeit, die der Rechner tatsächlich läuft. Man hatte dann überlegt, diese Angaben den Benutzer eingeben zu lassen. Dieser Ansatz wurde allerdings wieder verworfen, weil es dann genug Schlawiner gibt, die den Benchmarkwert drücken (durch paralleles Starten anderer Applikationen - eine WICHTIGE APPLIKATION wäre z.B. Unreal Tournament) und gleichzeitig eine geringere "active time" angeben, bloß um kurze WUs zu bekommen.

Michael.

[Patrick Keller]

Sowas ähnliches gibt es bereits: Nach Abliefern einer WU sieht man eine Performace Fraction, die sich nach dem Prozentualen Anteil der übrigen Deadlinezeit errechnet. Große projekte wie 858 oder 859 werden nur an Rechner mit einer Performance Fraction über x verteilt. Wie die Zahlen genau lauten wissen aba wohl nur die Jungs in Stanford.
Die größere WU wird in genau der selben restlichen Deadlinezeit zurückgeliefert wie die kleinere. zB: eine WU die man einen Tag rechnet und ne Deadline von 4 Tagen hat kommt nach 1 Tag mit 75% wieder. Eine WU die 10 Tage Deadline hat kommt nach 2,5 Tagen zurück, mit 75% Deadline. Die WUs sind ja alle gleich gebencht von daher ist das alles vollkommen sinnlos was wir hier diskutieren

EDIT: Und die Performance Fraction wird halt auch in die Zeit die der Rechner an ist einbezogen

[Michael H.W. Weber]

@Keller: SK hat völlig Recht. Es kommt sehr wohl darauf an, daß lahme Rechner KLEINE WUs bekommen und schnelle Rechner große WUs - wenn man die Produktivität des Gesamtprojekts IM STATISTISCHEN DURCHSCHNITT (!) optimal haben will. Andernfalls, wenn also schnelle Maschinen kleine WUs rechnen, werden natürlich diese Projekte umso schneller abgearbeitet. Man muß bei einem dc Projekt wie FAH hier einiges an Grips investieren, um die WU-Verteilung optimal zu steuern.
Ich würde auch sagen, daß eine völlige Steuerung über den Client - also über einen Benchmark nur begrenzt sinnvoll ist. Es dürfte nämlich vorkommen, daß man als Arbeitsgruppenleiter plötzlich z.B. besonderes Interesse an der SCHNELLEN Abarbeitung einer kleinen WU hat. Da würde dann eine clientbasierte Steuerung wenig Unterstützung bieten. Allerdings hat man dann natürlich die Möglichkeit, die Zahl der ausgegebenen WUs pro Projekt in Stanford zu verschieben. Insofern kann man also schon jetzt einigermaßen flexibel steuern.

Michael.

[Patrick Keller]

Man muß bei einem dc Projekt wie FAH hier einiges an Grips investieren, um die WU-Verteilung optimal zu steuern.

Soll das ne Anspielung auf meine Intelligenz sein ?

Natürlich, je schneller die WUs zurückgegeben werden, desto besser, aber wenn ein langsamer Rechner kleine WUs kriegt und ein schneller Rechner große WUs und beide Rechner ihre WU in der selben Zeit abliefern, geben sich die Projekte nichts. Wenn das ganze umgedreht wird, ist das kleine Projekt so viel schneller fertig wie das große Projekt langsamer fertig ist, im Endeffekt gibts auch hier keinen Unterschied. Wenn man jetzt den Fortschritt von Folding@home als ganzes sieht gibt das keinen Unterschied, wenn man einzelne Projekte pushen will schon, aber dann bräuchte man auch nur noch WUs dieser Projekte zu verteilen, kommt aufs selbe raus.
Vielleicht liegts echt an meiner Intelligenz

[Michael H.W. Weber]

Soll das ne Anspielung auf meine Intelligenz sein ?

Mit Nichten.

Natürlich, je schneller die WUs zurückgegeben werden, desto besser, aber wenn ein langsamer Rechner kleine WUs kriegt und ein schneller Rechner große WUs und beide Rechner ihre WU in der selben Zeit abliefern, geben sich die Projekte nichts. Wenn das ganze umgedreht wird, ist das kleine Projekt so viel schneller fertig wie das große Projekt langsamer fertig ist, im Endeffekt gibts auch hier keinen Unterschied. Wenn man jetzt den Fortschritt von Folding@home als ganzes sieht gibt das keinen Unterschied, wenn man einzelne Projekte pushen will schon, aber dann bräuchte man auch nur noch WUs dieser Projekte zu verteilen, kommt aufs selbe raus.

Tja, da hast Du wohl eine Kleinigkeit übersehen. Es gibt GROMACS. Und lahme Rechner sind oft alte Rechner, d.h. sie haben KEIN 3DNow! geschweige denn SSE/SSE2/SSE3. Wenn man also diese Rechner auf die großen WUs ansetzt - welche vornehmlich GROMACS WUs sind - wird das Gesamtprojekt überproportional verlangsamt.

Michael.

[Patrick Keller]

OK, das verstehe ich ja, aber dann würde kein allgemeines Benchen etwas bringen sondern lediglich eine Zuweisung der WUs (bzw. der Cores) an dafür optimierte Rechner (Tinker an nicht optimierte Rechner, Gromacs an SSE oder 3DNow! und DGromacs an SSE2) aber ich denke das fließt nicht in den Benchmarkwert ein.
Wir können eh nichts anderes tun als abzuwarten und unsere großen oder kleinen WUs fertigrechnen.
Keep on folding