Optimierte MilkyWay@home Applikation

Twodee schrieb:
das ist käse, bei MW gibt es derzeit faire credits. max. 6K pro Tag für einen extremen oced quad. und für optimierer sind max. 10K drin. wenn du wegen den credits jammern möchtest dann tu das bitte auch bei gpugrid, abc und seti. danke.

ps.: mir ist es egal ob DU es für wichtig hälst oder nicht. jammere doch lieber über die simap leute :P


ps.: "Habe mich mit MW bisher nicht beschäftigt aber geseben" ja da solltest du einiges nachholen um solche kommentare zu schreiben zu dürfen ;)
Zum Vergrößern anklicken....

Hierzu möchte gerne aus dem SetiGermany zitieren (ich weiß, dass es einen ähnlich kontrovers diskutierten Thread hier im P3D gibt):
Quelle: Berechnungen für Milkyway@home bitte umgehend stoppen!.
Wie ich sehe, hast Du die letzten wenigen Wochen bei MW 4,7 Mio. gemacht. Tagesoutput war bis vor kurzem noch >100k bei Dir (hatte nachgeschaut, weil ich Deinen Output hier bei den beiden KAV-Projekten vermisst habe).

wie es die meisten wahrscheinlich schon mitbekommen haben, ist das Projekt Milkyway@home derzeit etwas "derangiert".

Dies stellt sich dahingehend dar, als für das Projekt ein optimierte Anwendung verfügbar ist, die die Berechnung der einzelnen Workunits IMMENS beschleunigt. Diese optimierte Anwendung wird aber vom Projekt noch nicht als Standard versandt.

Weiterhin ergibt sich aus dem Credit-System des Projekts die Möglichkeit, auch mit - für BOINC-Verhältnissse - uralter Hardware mehrere Tausend Credits pro Tag "errechnen" zu können.

Dadurch gerät das komplette Credit-System aller BOINC-Projekte total durcheinander, und Statistiken werden konfus bis obsolet.


SETI.Germany empfhielt daher seinen Mitgliedern, die Berechnung für Milkyway@home ab sofort zu stoppen, bis die Projektbetreiber - wie auch von anderen Teams gefordert - diese Änderungen übernommen haben.

Diese Empfehlung habe ich auch so ähnlich in Englisch auf der Projektseite veröffentlicht.


Mal sehen, ob die Projekt-Betreiber nun reagieren, es wäre dringend nötig.
Zum Vergrößern anklicken....

Wie dem auch sei:
Anhand der aktuell PPD bei MW sehe ich, dass endlich reagiert wurde.
Nun hoffe ich jedoch noch, dass die bisher erwirtschafteten Credits bei MW noch nach unten hin nach dem aktuellen Creditschlüssel angepasst werden. Das wäre nur fair und gerecht, auch wenn das für viele bedeutet, dass sie mehrere Mio. Credits abgezogen bekommen. Aber demjenigen, der nur das wissenschaftliche Projekt unterstützen wollte, wird das egal sein. Treffen wird es dann diejenigen, die MW nur wg. des fehlgeleiteten (und mittlerweile korregierten?) Creditsystems gerechnet haben.
 
Hi MGeee,

ich will es mal etwas weniger drastisch als Twodee ausdrücken.
Kann es sein, dass Du da was nicht mitbekommen hast? ;)
Les Dir mal diesen thread durch:

http://www.planet3dnow.de/vbulletin/showthread.php?t=348575

Dann weist Du, worum es geht und kannst Dir Deine eigene Meinung neu bilden.
Aber nehm Dir dann heute nichts anderes mehr vor. Der thread ist ziemlich lang. ;D

Ich wünsche allen unseren crunchern einen schönen 2. Advent. *rose*
 
Bei mir lief die App von Anfang an, weil ich von Anfang an die nötigen Libs installiert hatte.
 
Tja das problem ist, das man die die Credits nicht anpassen kann! Sie wurden ja zu rechtens erwirtschaftet, nur mit dem unterschied das einige mit der gleichen hardware "schneller" also "mehr" arbeit erledigt haben, als andere. wie willst du das im nachhinein separieren? man könnte jetzt alle userer um einen gewissen faktor nach unten stutzen aber dann würden sehr viele, welche normal gerechnet haben mit der bremser-app, sehr laut schreien ;)

von den 4,7 habe ich ca, 3Mio mit meiner optimierten App gemacht, den rest mit der offiziellen linux-app.

ach ja lass bitte die kommentare von SG raus, die interessieren keinen, wenn ich gejammere lesen will dann gehe ich in deren board lesen ;)


ps.: fehlgeleitetes creditsystem? du mußt dich echt mal einlesen!
ps2: solange der sourcecode frei-verfügbar ist, kann jeder "legal" seine optimierte app bauen und einsetzen.
 
Hi Kater,

ich bewerte nicht, dass steht mir nicht zu.
Wenn es so rüber kommt, ist das keine Absicht.
Ich habe lediglich die Fakten dargestellt:
- Creditoutput pro Tag
- Gesamtpunktestand
usw.usw.

@Twodee
Ich frage mich gerade, wieviel Credits am Tag und boinc-combined ich erreicht hätte, wenn meine Systeme mit dem optimierten MW-client gecruncht hätten... bei Spin hatte ich ca. 17k bei Poem sind es ca. 27k bei MW wären es wohl 107k gewesen (nur eine Vermutung).
 
MGeee schrieb:
Hi Kater,

ich bewerte nicht, dass steht mir nicht zu.
Wenn es so rüber kommt, ist das keine Absicht.
Ich habe lediglich die Fakten dargestellt:
- Creditoutput pro Tag
- Gesamtpunktestand
usw.usw.

@Twodee
Ich frage mich gerade, wieviel Credits am Tag und boinc-combined ich erreicht hätte, wenn meine Systeme mit dem optimierten MW-client gecruncht hätten... bei Spin hatte ich ca. 17k bei Poem sind es ca. 27k bei MW wären es wohl 107k gewesen (nur eine Vermutung).
Zum Vergrößern anklicken....
womöglich. allerdings habe ich in mw nie meine gesamte hardware laufen lassen. nur max. 5quads (intel-oced über 3ghz, die amds haben da keine chance) unter linux mit 10K pro Quad, macht 50K am tag, die restlichen rechner hatte ich immer auf rcn und spinhenge.
als meine optimierte app fertig war hatte ich ca. 7 quads und 3 duals zu 25% bis 50% auf MW laufen und zwichen 100 und 200K am Tag gemacht (gemittelt). wenn ich alles auf 100% auf MW gehabt hätte, wäre ich da, wo MilkOpps jetzt ist, falls dir dieser name etwas sagt ;)
 
Twodee schrieb:
womöglich. allerdings habe ich in mw nie meine gesamte hardware laufen lassen. nur max. 5quads (intel-oced über 3ghz, die amds haben da keine chance) unter linux mit 10K pro Quad, macht 50K am tag, die restlichen rechner hatte ich immer auf rcn und spinhenge.
als meine optimierte app fertig war hatte ich ca. 7 quads und 3 duals zu 25% bis 50% auf MW laufen und zwichen 100 und 200K am Tag gemacht (gemittelt). wenn ich alles auf 100% auf MW gehabt hätte, wäre ich da, wo MilkOpps jetzt ist, falls dir dieser name etwas sagt ;)
Zum Vergrößern anklicken....

Ich sags mal so, bei Folding@Home findet das ja auch schon seit mehreren Jahren so statt.
Früher gab es nur einen normalen Client. Dann kam irgendwann mal der SMP-Client und man konnte ca. 8x soviel PPD rasuholen, als mit zwei oder viel Standard-Clients.
Parallel dazu gab es dann auch noch den PS3-Client (ca. 700 PPD) und seit ein paar Monaten gibt es einen NVidia-Client, mit dem man 5000 PPD und mehr mit nur einer Graka erreichen kann.
Das Prinzip ist wohl dasselbe, wie bei MW:
Deutlich höherer Output, weil einfach mehr berechnet wird (bei F@H weil z.B. Grakas schneller sind und bei MW weil die Software optimiert arbeitet).

Das war auch der Grund, warum ich irgendwann im letzten Sommer fast alle CPUs bei F@H abgezogen habe. Dort sind CPUs zum crunchen relativ "wertlos" geworden.

Wenn der MW-Output dauerhaft so geblieben wäre, hätte das wohl nur eins bedeutet:
Mit der Zeit hätten immer mehr Leute zu MW geswitcht und andere Projekte würden massiv leiden.

Prinzipiell ist das aber eine Grundsatzdiskussion (ich weiß, ich bin hier im Thread damit OT). Aber wäre es nicht besser, wenn alle Boinc-Projekte mit identischer Creditvergabe rechnen würden? Dazu müsste man ja nur die zugrundeliegende Rechenleistung beim Boinc-Start einmal festlegen (und zwar mit Boinc selber und nicht mit der Projekt-App). Stattdessen bringt jedes Projekt sein eigenes Benchmark-App mit und man erreicht bei unterschiedlichen Projekten einen teils sehr unterschiedliche Creditoutput (z.B. Spin vs. QMC vs. MW).
 
Zuletzt bearbeitet:
MGeee schrieb:
Ich sags mal so, bei Folding@Home findet das ja auch schon seit mehreren Jahren so statt.
Früher gab es nur einen normalen Client. Dann kam irgendwann mal der SMP-Client und man konnte ca. 8x soviel PPD rasuholen, als mit zwei oder viel Standard-Clients.
Parallel dazu gab es dann auch noch den PS3-Client (ca. 700 PPD) und seit ein paar Monaten gibt es einen NVidia-Client, mit dem man 5000 PPD und mehr mit nur einer Graka erreichen kann.
Das Prinzip ist wohl dasselbe, wie bei MW:
Deutlich höherer Output, weil einfach mehr berechnet wird (bei F@H weil z.B. Grakas schneller sind und bei MW weil die Software optimiert arbeitet).

Das war auch der Grund, warum ich irgendwann im letzten Sommer fast alle CPUs bei F@H abgezogen habe. Dort sind CPUs zum crunchen relativ "wertlos" geworden.
Zum Vergrößern anklicken....
Andere Baustelle, allerdings ist das nicht das gleiche, da es dort nie den sourcecode für jedermann gab und man somit duch eigene Optimierungen sich einen Vorteil hatte ziehen können. btw. warum hast du dir nicht wie die anderen einfach grakas besorgt und damit gleichgezogen?

MGeee schrieb:
Wenn der MW-Output dauerhaft so geblieben wäre, hätte das wohl nur eins bedeutet:
Mit der Zeit hätten immer mehr Leute zu MW geswitcht und andere Projekte würden massiv leiden.

Prinzipiell ist das aber eine Grundsatzdiskussion (ich weiß, ich bin hier im Thread damit OT). Aber wäre es nicht besser, wenn alle Boinc-Projekte mit identischer Creditvergabe rechnen würden? Dazu müsste man ja nur die zugrundeliegende Rechenleistung beim Boinc-Start einmal festlegen (und zwar mit Boinc selber und nicht mit der Projekt-App).
Zum Vergrößern anklicken....
meinst du den Boinc-Bench? Dieser ist aber absulut ungeeigent um die tatsächliche Rechenleistung eines Systems zu ermitteln.

MGeee schrieb:
Stattdessen bringt jedes Projekt sein eigenes Benchmark-App mit und man erreicht bei unterschiedlichen Projekten einen teils sehr unterschiedliche Creditoutput (z.B. Spin vs. QMC vs. MW).
Zum Vergrößern anklicken....
Wie meinst du das? Meistens orientiert man sich doch an Seti, d.h. was ein genormtes System bei Seti an Credits macht, macht es eben in QMC auch. Das Problem ist aber das eben dieses System in anderen Projekten mit anderen Berechnungen schneller oder langsamer als anders konfigurierte Systeme arbeitet, wodurch es aben zu diesen breiten Credit-Unterschieden kommt.
 
MGeee schrieb:
Hi Kater,

ich bewerte nicht, dass steht mir nicht zu.
Wenn es so rüber kommt, ist das keine Absicht.
Ich habe lediglich die Fakten dargestellt:
- Creditoutput pro Tag
- Gesamtpunktestand
usw.usw.

@Twodee
Ich frage mich gerade, wieviel Credits am Tag und boinc-combined ich erreicht hätte, wenn meine Systeme mit dem optimierten MW-client gecruncht hätten... bei Spin hatte ich ca. 17k bei Poem sind es ca. 27k bei MW wären es wohl 107k gewesen (nur eine Vermutung).
Zum Vergrößern anklicken....
Wenn Du Twodee kritisierst, mußt Du das mindestens genauso auch auf mich beziehen.

Aber ich gebe Dir mal einen kurzen Abriß des Geschehens:
Aus genau den Gründen, die Du anführst haben wir mit unseren optimierten Versionen nicht voll auf unsere Accounts gerechnet. Was glaubst Du, wo die 24 Millionen credits in 30 Tagen für diesen teamlosen "Milksop at try" hergekommen sind? Wir wollten den Betreiber unter Druck setzen ohne uns oder auch dem P3D-Team einen riesigen Vorteil zu verschaffen. Diese 24 Millionen hätten genauso gut auch auf Twodees und meinem Account (und damit bei P3D) landen können.
Und das war noch lange nicht das Maximum. Die erste Woche waren das 6 Quads und 6 Duals, später dann nur noch 6 Duals (3 davon AthlonMPs@1.33GHz *buck*). Ein einziger X2@3.1GHz hat mit meiner Version etwa 245k/Tag gemacht, die MPs etwa 90k. Ein 45nm Quad@3GHz wäre so bei etwa 500k gelandet. Wenn Du Dir anschaust, was Twodee und mir an Rechnern insgesamt zur Verfügung steht, hätte jeder von uns locker mehrere Millionen pro Tag machen können. Da wäre Atlas bei Einstein nicht hinterhergekommen.

Parallel zu dieser Demonstration haben wir die wesentlichen Optimierungsmöglichkeiten veröffentlicht (der reine Fakt der Ineffizienz war dem Betreiber schon Monate bekannt). Nach einem Monat haben wir dann aufgehört für Milksop zu rechnen und mit Einverständnis des Betreibers Binaries der optimierten Version für Win und Linux veröffentlicht. Diese waren exakt auf dem Stand, mit dem wir zuletzt gerechnet haben. Aus Kompatibilitätsgründen wurden sie allerdings ohne SSE/2/3 und auch mit älteren Compilern erzeugt. Damit konnte jeder ein vom Betreiber eingerichtetes Limit erreichen, das die granted credits auf 0.03 pro Sekunde beschränkt (war anfangs bei 0.06). Dies haben alle Rechner ab PentiumPro 150MHz erreicht und verdeutlicht nochmal den Geschwindigkeitsvorteil der Verbesserungen.

Jetzt hat der Betreiber endlich reagiert und die von uns vorgeschlagenen Änderungen in die offizielle Version eingebaut. Daraufhin hat auch SG die Empfehlung, nicht mehr MW zu rechnen, wieder aufgehoben.

PS: MW ist im Moment übrigens eines der wenigen Projekte, wo AMDs schneller sind als Intels (wenn man keinen Core i7 auffährt) :w_grins:
 
Zuletzt bearbeitet:
auf meinem Dual XP funkioniert die opti app nicht
MW ordner geleert
neue wu's geladen
MW angehalten
Twodee's opti geladen
MW wieder gestartet
die opti app (98KB) wird nicht genommen
MW rechnet mit seiner runtergeladenen app (244KB)
:w_verwirrt:
 
Gipsel schrieb:
Wenn Du Twodee kritisierst, mußt Du das mindestens genauso auch auf mich beziehen.

Aber ich gebe Dir mal einen kurzen Abriß des Geschehens:
Aus genau den Gründen, die Du anführst haben wir mit unseren optimierten Versionen nicht voll auf unsere Accounts gerechnet. Was glaubst Du, wo die 24 Millionen credits in 30 Tagen für diesen teamlosen "Milksop at try" hergekommen sind? Wir wollten den Betreiber unter Druck setzen ohne uns oder auch dem P3D-Team einen riesigen Vorteil zu verschaffen. Diese 24 Millionen hätten genauso gut auch auf Twodees und meinem Account (und damit bei P3D) landen können.
Und das war noch lange nicht das Maximum. Die erste Woche waren das 6 Quads und 6 Duals, später dann nur noch 6 Duals (3 davon AthlonMPs@1.33GHz *buck*). Ein einziger X2@3.1GHz hat mit meiner Version etwa 245k/Tag gemacht, die MPs etwa 90k. Ein 45nm Quad@3GHz wäre so bei etwa 500k gelandet. Wenn Du Dir anschaust, was Twodee und mir an Rechnern insgesamt zur Verfügung steht, hätte jeder von uns locker mehrere Millionen pro Tag machen können. Da wäre Atlas bei Einstein nicht hinterhergekommen.

Parallel zu dieser Demonstration haben wir die wesentlichen Optimierungsmöglichkeiten veröffentlicht (der reine Fakt der Ineffizienz war dem Betreiber schon Monate bekannt). Nach einem Monat haben wir dann aufgehört für Milksop zu rechnen und mit Einverständnis des Betreibers Binaries der optimierten Version für Win und Linux veröffentlicht. Diese waren exakt auf dem Stand, mit dem wir zuletzt gerechnet haben. Aus Kompatibilitätsgründen wurden sie allerdings ohne SSE/2/3 und auch mit älteren Compilern erzeugt. Damit konnte jeder ein vom Betreiber eingerichtetes Limit erreichen, das die granted credits auf 0.03 pro Sekunde beschränkt (war anfangs bei 0.06). Dies haben alle Rechner ab PentiumPro 150MHz erreicht und verdeutlicht nochmal den Geschwindigkeitsvorteil der Verbesserungen.

Jetzt hat der Betreiber endlich reagiert und die von uns vorgeschlagenen Änderungen in die offizielle Version eingebaut. Daraufhin hat auch SG die Empfehlung, nicht mehr MW zu rechnen, wieder aufgehoben.

PS: MW ist im Moment übrigens eines der wenigen Projekte, wo AMDs schneller sind als Intels (wenn man keinen Core i7 auffährt) :w_grins:
Zum Vergrößern anklicken....

ich stimme dir in alles zu bis auf den letzten punkt. die x4s haben in mw gegen einen 45nm Core2 unter vista64 bit mit der standard-app keine chance. [core2(45nm)@3.2Ghz[winxp64]: unter 1500 sekunden mit der standard 07er app, bei 39 credits]
 
Zuletzt bearbeitet:
Twodee schrieb:
ich stimme dir in alles zu bis auf den letzten punkt. die x4s haben in mw gegen einen 45nm Core2 unter vista64 bit mit der standard-app keine chance. [core2(45nm)@3.2Ghz[winxp64]: unter 1500 sekunden mit der standard 07er app, bei 39 credits]
Zum Vergrößern anklicken....
Was haben die denn da schon wieder gemacht? Unter Win32 haben die Core2 (auch 45nm) nämlich keine Chance. Auch gewinnen die AMDs durch die 64Bit App praktisch überhaupt nichts. Und die ersten 3 Einträge im C-Index sind doch mit Deiner App gelaufen, die kann man ja nicht rechnen. Also warum werden die 45nm Core2 unter 64Bit soviel schneller, die AMDs aber nicht :w_verwirrt:

Btw., kannst Du im C-Index noch einen Core i7 ohne HT zur CPU-Auswahl hinzufügen?
 
Gipsel schrieb:
Was haben die denn da schon wieder gemacht? Unter Win32 haben die Core2 (auch 45nm) nämlich keine Chance. Auch gewinnen die AMDs durch die 64Bit App praktisch überhaupt nichts. Und die ersten 3 Einträge im C-Index sind doch mit Deiner App gelaufen, die kann man ja nicht rechnen. Also warum werden die 45nm Core2 unter 64Bit soviel schneller, die AMDs aber nicht :w_verwirrt:

Btw., kannst Du im C-Index noch einen Core i7 ohne HT zur CPU-Auswahl hinzufügen?
Zum Vergrößern anklicken....

ich hab @home (da bin ich gerade nicht) den test mit der standard-07-app unter xp64 gemacht, und er brauchte unter 25 minuten, habe ich aber aus zeitmangel nicht eingetragen und jetzt sind die werte auf der projekteseite weg :( - heute abend wenn ich back@home bin kümmere ich mich drum (auch um die cpu-liste auf der ci-seite).
 
Mein Atom330 mit HT , standart-07er-app XP64 verblüfft mich etwas:

nm_stripe86 , 5,360.88sec , 41,09Credits
nm_stripe82 , 10,057.08sec , 39.85Credits

Warum ist der Zeitunterschied so extrem?

Im Vergleich zum Q9450 Linux64:

nm_stripe86 , 2,127.20sec , 41.09Credits
nm_stripe82 , 2,070.55sec , 39.85Credits

Da dauern die stripe86 sogar etwas länger.

cu JagDoc
 
JagDoc schrieb:
Mein Atom330 mit HT , standart-07er-app XP64 verblüfft mich etwas:

nm_stripe86 , 5,360.88sec , 41,09Credits
nm_stripe82 , 10,057.08sec , 39.85Credits

Warum ist der Zeitunterschied so extrem?

Im Vergleich zum Q9450 Linux64:

nm_stripe86 , 2,127.20sec , 41.09Credits
nm_stripe82 , 2,070.55sec , 39.85Credits

Da dauern die stripe86 sogar etwas länger.

cu JagDoc
Zum Vergrößern anklicken....
Wahrscheinlich hast Du eine der "verunglückten" stripe86 WUs bekommen. Die machen nur die Hälfte von dem, was eigentlich geplant war. Umgekehrt gibt es das auch, einige WUs laufen so lange wie die normalen ~40 credit WUs, es gibt aber nur etwa 20 dafür.
 
JagDoc schrieb:
Mein Atom330 mit HT , standart-07er-app XP64 verblüfft mich etwas:

nm_stripe86 , 5,360.88sec , 41,09Credits
nm_stripe82 , 10,057.08sec , 39.85Credits

Warum ist der Zeitunterschied so extrem?

Im Vergleich zum Q9450 Linux64:

nm_stripe86 , 2,127.20sec , 41.09Credits
nm_stripe82 , 2,070.55sec , 39.85Credits

Da dauern die stripe86 sogar etwas länger.

cu JagDoc
Zum Vergrößern anklicken....

Moin
auf einem meiner X2 brauchen die 86 (r1 - r8 oder so) nur 1410 sec anstatt ca 2600 bei voller Punktzahl
aber komischerweise auch nur auf diesem einem Rechner ???
 
Twodee schrieb:
Ich habe die 07er Version fertig.

ein 3.2Ghz Quad benötigt nur noch 700 Sekunden.

Es gibt eine normale, sse und sse2 version: http://stats.planet3dnow.biz/Apps/MW.rar

Ich hoffe das sie diesmal geht, bei mir laufen alle 3 Versionen.
Zum Vergrößern anklicken....
Dnake, das Archiv scheint aber kaputt zu sein. Hat bei mir 357kb, Winrar meldet aber einen zerstörten Dateikopf und im Archiv finde ich nur den Unterordner "normal"

Lade es dochmal bei www.file-upload.net hoch und poste den Link
 
Falls es jemanden interessieren sollte:

Der Unterschied zwischen der Betreiber-App 06 und Betreiber-App 07 sind gute 10% Speed, dafür wird das Ergebnis ab der 15. Stelle nach dem Komma ungenauer [was vorher nicht der Fall war].
 

Ähnliche Themen

tspoon
KI Projekt 2024
Antworten
3
Aufrufe
825
vinacis_vivids
vinacis_vivids
E555user
News PBO2 und GPUopen.com - umfangreiches Update von AMD
Antworten
2
Aufrufe
2K
E555user
E555user
koschi
Einstein@home - allgemeiner Austausch (News, Forenfunde, HowTo, etc.)
17 18 19
Antworten
470
Aufrufe
43K
NEO83
NEO83
TAL9000
9. Pentathlon 2018 - Asteroids@home (Stadtlauf)
13 14 15
Antworten
368
Aufrufe
42K
sompe
S
O
app_config.xml
5 6 7
Antworten
162
Aufrufe
60K
enigmation
enigmation

Aktuelle Aktionen

BOINC Games 2024
Forumsthread
Webseite

Wichtige Links

News zum Thema DC

Zurück
Oben Unten