MilkyWay@Home

Also wenn ich mir ansehe, was ne einzelne 4870 schon für Anforderungen an die Kühlung / Geräuschkulisse stellt, dann bin ich mir ziemlich sicher, dass ne 4870 X2 unter Volldampf nichts für empfindliche Naturen ist. Und auch nichts für Leute, die sich ab und an im gleichen Raum wie der Rechner aufhalten (müssen).
Bei 2 PCIe Slots würde ich daher 2 einzelne 4870'er nehmen. Bei einem slot und einem Rechner finde ich die 4890 keine schlechte Wahl: Stromverbrauch gleich dem der 4870, also gerade noch zu handhaben (verglichen mit ner X2). Dabei für die ~60% Aufpreis mit OC zwar nur ~15% schneller, aber in absoluten credits/Tag wäre das trotzdem nicht schlecht: für 60€ mehr 15k credits/Tag mehr..

MrS

Im Moment herrscht Flaute in der WU-Versorgung...

24.07.2009 22:32:50 Milkyway@home Sending scheduler request: To fetch work.
24.07.2009 22:32:50 Milkyway@home Requesting new tasks
24.07.2009 22:32:55 Milkyway@home Scheduler request completed: got 0 new tasks
24.07.2009 22:32:55 Milkyway@home Message from server: No work available

Neue Wu´s sind wieder da

Übersetzungswürdige News, wie ich finde:

Zitat von http://milkyway.cs.rpi.edu/milkyway/

Credit Reduction
September 11, 2009
Milkyway's credit awarded has been a bit too high for awhile now, and we're bringing it down to be in line more with other projects. We've been using a credit multiplier of 7.5 per double precision FLOP and other projects are using around 5.4 per double precision FLOP. We're reducing our multipler to this, so credit should be down around 20-30%. I know everyone hates credit reductions, but it was really needed. We also have some performance improvements for CUDA and ATI applications on the way out, so hopefully it won't be too bad. As usual, try to keep the forum flaming about the credit changes somewhat civil.

Zitat von auf Deutsch

Creditsenkung
11. September 2009
Die von Milkyway vergebenen Credits waren nun schon eine ganze Zeit etwas zu hoch und wir senken sie, um mehr auf Augenhöhe mit anderen Projekten zu liegen. Wir haben einen Multiplikator von 7,5 pro FLOP in doppelter Genauigkeit verwendet und andere Projekte benutzen um 5,4. Wir werden unseren Multiplikator auf diesen Wert reduzieren, also werden die Credits um 20-30% sinken. Ich weiß, dass jeder Creditsenkungen hasst, aber das war wirklich nötig. Außerdem haben wir ein paar Leistungsverbesserungen für die CUDA- und ATI-Anwendungen in Vorbereitung, also wird das hoffentlich nicht zu schlimm. Wie immer, versucht, die Flamewars im Forum über die Creditänderung etwas friedlich zu halten.

Zitat von pschoefer[SPEG]

Wie immer, versucht, die Flamewars im Forum über die Creditänderung etwas friedlich zu halten.

Da besorg' ich mir doch gleich mal Chips und was leckeres zu trinken: das wird, wie immer bei der Thematik, wieder extrem spannend und unterhaltsam werden...

Ich finds gut und seit längerem überfällig...

Wir haben einen Multiplikator von 7,5 pro FLOP in doppelter Genauigkeit verwendet und andere Projekte benutzen um 5,4. Wir werden unseren Multiplikator auf diesen Wert reduzieren, also werden die Credits um 20-30% sinken. Ich weiß, dass jeder Creditsenkungen hasst, aber das war wirklich nötig.

find ich gut.

Außerdem haben wir ein paar Leistungsverbesserungen für die CUDA- ...

find ich sehr gut

Zitat von UL1

Da besorg' ich mir doch gleich mal Chips und was leckeres zu trinken: das wird, wie immer bei der Thematik, wieder extrem spannend und unterhaltsam werden...

Ich setz mich mit dazu und lach mich schlapp. Da wird die Karawane der Geier wohl weiterziehen

Zitat von aendgraend

Ich setz mich mit dazu und lach mich schlapp. Da wird die Karawane der Geier wohl weiterziehen

Ich bleib' da...

Na nun habt ihr mich doch neugierig gemacht dort in deren Forum auch mal zu lesen.

Zitat von MilkyWay@home
Die von Milkyway vergebenen Credits waren nun schon eine ganze Zeit etwas zu hoch und wir senken sie, um mehr auf Augenhöhe mit anderen Projekten zu liegen. Wir haben einen Multiplikator von 7,5 pro FLOP in doppelter Genauigkeit verwendet und andere Projekte benutzen um 5,4. Wir werden unseren Multiplikator auf diesen Wert reduzieren, also werden die Credits um 20-30% sinken.

Habe ich kein Problem mit. Bin nur echt gespannt wieviele nun umschwenken werden

Zitat von MilkyWay@home
Außerdem haben wir ein paar Leistungsverbesserungen für die CUDA- und ATI-Anwendungen in Vorbereitung

Finde ich sehr gut

Zitat von ltom2607

Habe ich kein Problem mit. Bin nur echt gespannt wieviele nun umschwenken werden

Da schwenkt genau keiner der ATI Karten Benutzer um. Da werden einige meckern und mit Fernbleiben drohen, es interessiert keinen und sie bleiben doch, da sie ja nirgendwo sonst so viele Punkte mit der Karte erzielen können.

Falls noch jemand mit der CPU bei Milkyway ist, dann geht er vielleicht, das wird aber niemandem auffallen.

Exakt. ATI-Besitzer haben momentan als einzige Alternative nur Collatz...und da ist die ATI-App (noch?) nicht so leistungsfähig wie bei MW. Ziehen die da mal gleich oder übertrumpfen die MW-App sogar (Gipsel ist da ja auch involviert)...dann geht der Exodus los...

So, und nun ist MW nicht erreichbar:

13.09.2009 12:27:13 Milkyway@home Sending scheduler request: Requested by user.
13.09.2009 12:27:13 Milkyway@home Reporting 48 completed tasks, not requesting new tasks
13.09.2009 12:27:23 Milkyway@home Scheduler request completed: got 0 new tasks
13.09.2009 12:27:23 Milkyway@home Message from server: Server can't open database

Zitat von UL1

ATI-Besitzer haben momentan als einzige Alternative nur Collatz...und da ist die ATI-App (noch?) nicht so leistungsfähig wie bei MW. Ziehen die da mal gleich oder übertrumpfen die MW-App sogar (Gipsel ist da ja auch involviert)...dann geht der Exodus los...

Das wird vielleicht nicht passieren, da Collatz nicht ganz so perfekt für GPUs geeignet ist (bedingte Sprünge können GPUs nicht ganz so gut). Da wird der Geschwindigkeitsvorsprung gegenüber CPUs also tendenziell etwas kleiner ausfallen (obwohl GPUs dort den Nachteil mit double precision nicht haben).

Meine ATI-App für Collatz (liegt schon über einen Monat bei Slicker rum) ist bestimmt 10 mal so schnell, wie die aktuelle, allerdings habe ich mich auch an die CPU-App rangemacht und die um etwa den gleichen Faktor beschleunigt. Slicker knabbert momentan nur noch an der CUDA-Umsetzung (gab wohl die letzten Tage ein paar Fortschritte), dann gehen die online.

Wenn alles um den gleichen Faktor schneller werden würde, ändert sich an der Creditsituation nichts, da die Credits mit der CPU-Version kalibriert werden, aber wahrscheinlich gibt es einige Verschiebungen.


Hinzugefügter Post:

Zitat von ltom2607

Habe ich kein Problem mit. Bin nur echt gespannt wieviele nun umschwenken werden

Gar keiner, weil die neue 0.20 App für ATIs die Credit-Senkung locker auffängt. Kommt wohl heute Abend, für CPUs (Steigerung nicht ganz so groß) gibt es sie schon.

Also meine ersten sind durch, läuft jetzt bis jetzt sauber durch, ein paar WUs mit Berechnungsfehler sind allerdings auch dabei.

Derzeit noch auf dem 6.10.4, aber der bleibt wg. der schon von Patrick im BOINC-Versions-Thread beschriebenen Problem, dass alle WUs kurz anlaufen und dann verdrängt werden, nicht lange drauf.

Hier mal ne WU:

<core_client_version>6.10.4</core_client_version>
<![CDATA[
<stderr_txt>
Running Milkyway@home ATI GPU application version 0.20 (Win64) by Gipsel
ignoring unknown input argument in app_info.xml: --device
ignoring unknown input argument in app_info.xml: 0
CPU: AMD Phenom(tm) II X4 940 Processor (4 cores/threads) 3.00914 GHz (211ms)

CAL Runtime: 1.4.403
Found 1 CAL device

Device 0: ATI Radeon HD 4800 (RV770) 512 MB local RAM (remote 1855 MB cached + 1855 MB uncached)
GPU core clock: 815 MHz, memory clock: 925 MHz
800 shader units organized in 10 SIMDs with 16 VLIW units (5-issue), wavefront size 64 threads
supporting double precision

0 WUs already running on GPU 0
Starting WU on GPU 0

main integral, 320 iterations
predicted runtime per iteration is 130 ms (33.3333 ms are allowed), dividing each iteration in 4 parts
borders of the domains at 0 400 800 1200 1600
Calculated about 8.22242e+012 floatingpoint ops on GPU, 1.23583e+008 on FPU. Approximate GPU time 41.8734 seconds.

probability calculation (stars)
Calculated about 3.34818e+009 floatingpoint ops on FPU.

WU completed.
CPU time: 2.02801 seconds, GPU time: 41.8734 seconds, wall clock time: 43.125 seconds, CPU frequency: 3.00917 GHz

</stderr_txt>
]]>

Derzeit auf nem Win7 64bit, ATI Catalyst 9.9, BOINC 6.10.4, Phenom II

Zitat von SDI

Also meine ersten sind durch, läuft jetzt bis jetzt sauber durch, ein paar WUs mit Berechnungsfehler sind allerdings auch dabei.

Derzeit noch auf dem 6.10.4, aber der bleibt wg. der schon von Patrick im BOINC-Versions-Thread beschriebenen Problem, dass alle WUs kurz anlaufen und dann verdrängt werden, nicht lange drauf.

Hier mal ne WU:

Derzeit auf nem Win7 64bit, ATI Catalyst 9.9, BOINC 6.10.4, Phenom II

Ein Link in unser Forum mit der neuen Version würde Deinen Mitstreitern vielleicht auch helfen

Urgs, in deinem Post eins über mir hast du einen link mit "gibt es sie schon" gesetzt und ich hatte hier schon die GPU-Version vermutet

Anyway, danke fürs nachholen!

Hast du vielleicht hierfür ne Erklärung? Krieg ich derzeit bei geschätzten 10% der WUs...

<core_client_version>6.10.4</core_client_version>
<![CDATA[
<message>
Unzulässige Funktion. (0x1) - exit code 1 (0x1)
</message>
<stderr_txt>
Running Milkyway@home ATI GPU application version 0.20 (Win64) by Gipsel
ignoring unknown input argument in app_info.xml: --device
ignoring unknown input argument in app_info.xml: 0
Couldn't find input file [astronomy_parameters.txt] to read astronomy parameters.
APP: error reading astronomy parameters: 1

</stderr_txt>
]]>

Edith: Danke für die Antwort im obigen P3D-Forums-Thread

@Gipsel
Die Milkyway@home version 0.20 (Win64, SSE3) by Gipsel macht auf meinem Intel Q6600 WinXP 64 bit SP2 die kürzeren WUs alle invalid. Selbe Problem auch mit dem Vista Home Premium 64 bit SP2 Laptop nur werden hier nicht alle kurzen WUs invalid. Der Intel V8 e5420 WinXP 64 bit SP2 zeigt dieses Verhalten bisher nicht.
MSVC++ 2005 SP1 runtime package mitsamt den letzten Updates ist auf allen Rechnern installiert.

Beispiel WUs die invalid werden:
gs_constrainted_82_2s_4_2076769_1252904461_0
Workunit 102071835
de_constrainted_82_2s_4_2091592_1252905720_0
102086658

Intel Q6600 WinXP 64 bit SP2 rennt nun wieder mit der vorherigen app Milkyway@home version 0.19 by Gipsel problemlos.

@edit
Auch der Intel V8 e5420 WinXP 64 bit SP2 macht nun einige kurzen WUs invalid.
An den Laptop und V8 komme ich von hier @work nicht ran um die vorherige Milkyway@home version 0.19 by Gipsel wieder zu verwenden.

Kann momentan diese Milkyway@home version 0.20 (Win64, SSE3) by Gipsel niemanden empfehlen, denn der V8 und Laptop hatten bisher noch nie eine Invalid WU bei einem der Projekte abgeliefert.

Zitat von Carnal

@Gipsel
Die Milkyway@home version 0.20 (Win64, SSE3) by Gipsel macht auf meinem Intel Q6600 WinXP 64 bit SP2 die kürzeren WUs alle invalid. Selbe Problem auch mit dem Vista Home Premium 64 bit SP2 Laptop nur werden hier nicht alle kurzen WUs invalid. Der Intel V8 e5420 WinXP 64 bit SP2 zeigt dieses Verhalten bisher nicht.
MSVC++ 2005 SP1 runtime package mitsamt den letzten Updates ist auf allen Rechnern installiert.

Beispiel WUs die invalid werden:
gs_constrainted_82_2s_4_2076769_1252904461_0
Workunit 102071835
de_constrainted_82_2s_4_2091592_1252905720_0
102086658

Intel Q6600 WinXP 64 bit SP2 rennt nun wieder mit der vorherigen app Milkyway@home version 0.19 by Gipsel problemlos.

@edit
Auch der Intel V8 e5420 WinXP 64 bit SP2 macht nun einige kurzen WUs invalid.
An den Laptop und V8 komme ich von hier @work nicht ran um die vorherige Milkyway@home version 0.19 by Gipsel wieder zu verwenden.

Kann momentan diese Milkyway@home version 0.20 (Win64, SSE3) by Gipsel niemanden empfehlen, denn der V8 und Laptop hatten bisher noch nie eine Invalid WU bei einem der Projekte abgeliefert.

Von diesen etwas kürzeren WUs sind ziemlich viele einfach kaputt, sprich, da stehen unsinnige Werte als Parameter drin. Das habe ich Travis schon berichtet und er schaut es sich an. Bis dahin ist es einfach Glück oder Pech, wie viele man davon bekommt. Die Fehler treten auch nicht nur mit den neuen 0.20-Versionen auf, sondern mit allen (was bei defekten WUs ja auch klar ist).

Mit der Milkyway@home version 0.19 by Gipsel laufen diese WUs aber alle durch ob nun wirklich dabei was rauskommt sei erstmal egal aber als INVALID werden die nicht markiert.

Der erste Schwung mit der neuen App ist durch und wurde gegranted.

Zitat von Carnal

Mit der Milkyway@home version 0.19 by Gipsel laufen diese WUs aber alle durch ob nun wirklich dabei was rauskommt sei erstmal egal aber als INVALID werden die nicht markiert.

Glaube ich nicht. Es gibt im MW-Forum auch eine Menge Leute, die zuerst die Fehler hatten (die ersten Posts dazu kamen schon einen halben Tag bevor die 0.20 überhaupt veröffentlicht wurde!) und erst danach auf 0.20 umgestiegen sind.

Außerdem hat Travis inzwischen bestätigt, daß es ein serverseitiges Problem mit den WUs gibt:

Zitat von Travis

I think I'm seeing the problem now. For some reason it looks like some of the search data is getting corrupted on the server... maybe a memory leak, i'm not sure.

Wie ich auch im MW-Forum schrieb, kann ich trotz der ganzen vor der Veröffentlichung durchgeführten Tests natürlich nicht hundertprozentig ausschließen, daß es irgendwelche Probleme (z.B. mit neuen WU-Typen) gibt. Während der Tests (auch schon "live" mit echten WUs) gab es wirklich null Probleme mit ungültigen Ergebnissen. Ich habe wirklich sowohl für Test-WUs als auch echte mit verschiedenen Parametern die Apps ausprobiert, immer kamen da ordentliche Ergebnisse raus. Wenn Travis Probleme mit einer "normalen" WU findet, werde ich natürlich nach einem Fehler suchen. Allerdings ist dies bisher nicht der Fall.

MW testet gerade neue Optimierungsroutinen. Es kann auch einfach sein, daß die aus dem Ruder laufen und nicht konvergieren, was dann zu WUs mit abstrusen Parametern führt (und die ungültigen WUs haben abstruse Parameter, wie ich schon im MW-Forum gepostet habe). Für diese WUs kann dann natürlich auch kein vernünftiges Ergebnis berechnet werden, von keiner Version. Es gibt höchstens noch einen Unterschied, ob der Validator die WUs sofort als ungültig erkennt, oder es credits dafür gibt. Wovon das abhängt ist nicht ganz klar, da Travis auch geschrieben hat, daß der Validator momentan Probleme hat, die App-Signaturen im Ergebnisfile zu lesen. Und ohne Signatur gibt es ebenfalls keine Credits.

Zitat von Gipsel

Glaube ich nicht. Es gibt im MW-Forum auch eine Menge Leute, die zuerst die Fehler hatten (die ersten Posts dazu kamen schon einen halben Tag bevor die 0.20 überhaupt veröffentlicht wurde!) und erst danach auf 0.20 umgestiegen sind.

Nachts die neue app auf die Rechner gemacht der Quad bei den kurzen WUs alle lauter INVALID auf den anderen Rechnern nur vereinzelt INVALID WUs zu sehen, vorher alles ausnahmslos gültige Ergebnisse auf allen 3 Rechnern. Vor dem in die Arbeit gehen Vormittags konnte ich zeitmäßig nur dem Quad die Milkyway@home version 0.19 SSSE3 schnell wieder geben. Ganzen Tag nicht eine INVALID mit dem Quad. Komme dann um 20:45 nachhause gebe dem Quad wieder die Milkyway@home version 0.20 (Win64, SSE3). Erste kurze WU sofort wieder kaputt, an Zufall glaube ich da nicht mehr. Nach 2h nur kaputter kurzer WUs wieder die Milkyway@home version 0.19 SSSE3 dem Quad gegeben und die kurzen WUs laufen wieder alle als VALID durch.

Mag sein, dass einige der kurzen WUs defekt sind aber mit der Milkyway@home version 0.20 (Win64, SSE3) sind alle auf dem Intel Quad INVALID.
10-15% Geschwindigkeitsgewinn sind sichtbar aber mehr als 50% der WUs sind eben die kurzen und die sind alle INVALID, gleichbedeutend mit dickem Creditverlust.

Zitat von Carnal

Mag sein, dass einige der kurzen WUs defekt sind aber mit der Milkyway@home version 0.20 (Win64, SSE3) sind alle auf dem Intel Quad INVALID.

Wäre schon komisch, wenn die auf AMDs laufen und auf Intels Probleme machen, war immerhin der Intel-Compiler am Werk. Aber ich kann Dich beruhigen, Fehler treten unabhängig von der Prozessormarke auf.
Aber gehen wir der Sache doch mal auf den Grund. Bitte führe mal folgende Schritte aus:
1. kopiere die "astronomy_0.20_x64_SSE3.exe" in irgendein leeres Verzeichnis.
2. erstelle in diesem Verzeichnis eine Datei mit dem Namen "astronomy_parameters.txt"
3. kopiere folgenden Text in diese Datei:

number_parameters: 4
background_weight: 0.000000
background_parameters[4]: 1.0000000000, 0.5717130000, 12.3121190000, 1.0000000000
background_step[4]: 0.0200000000, 0.0000040000, 0.0000800000, 0.0200000000
background_min[4]: 0.0000000000, 0.3000000000, 1.0000000000, 0.1000000000
background_max[4]: 3.0000000000, 1.0000000000, 30.0000000000, 3.0000000000
optimize_parameter[4]:  0, 1, 1, 0
number_streams: 2, 5
stream_weight: -3.305187
stream_weight_step: 0.000001
stream_weight_min: -20.000000
stream_weight_max: 20.000000
optimize_weight: 1
stream_parameters[5]: 148.0102570000, 22.4539020000, 0.4203500000, -0.4688580000, 0.7605790000
stream_step[5]: 0.0000300000, 0.0000400000, 0.0000600000, 0.0000400000, 0.0000040000
stream_min[5]: 133.0000000000, 2.3000000000, -6.2831853072, -6.2831853072, 0.1000000000
stream_max[5]: 249.0000000000, 45.6000000000, 6.2831853072, 6.2831853072, 20.0000000000
optimize_parameter[5]:  1, 1, 1, 1, 1
stream_weight: -1.361644
stream_weight_step: 0.000001
stream_weight_min: -20.000000
stream_weight_max: 20.000000
optimize_weight: 1
stream_parameters[5]: 177.8842380000, 23.8828920000, 1.2106390000, -1.6119740000, 8.5343780000
stream_step[5]: 0.0000300000, 0.0000400000, 0.0000600000, 0.0000400000, 0.0000040000
stream_min[5]: 133.0000000000, 2.4000000000, -6.2831853072, -6.2831853072, 0.1000000000
stream_max[5]: 249.0000000000, 45.6000000000, 6.2831853072, 6.2831853072, 20.0000000000
optimize_parameter[5]:  1, 1, 1, 1, 1
convolve: 60
sgr_coordinates: 0
wedge: 20
r[min,max,steps]: 16.000000, 22.500000, 200
mu[min,max,steps]: 133.000000, 249.000000, 200
nu[min,max,steps]: -1.250000, 1.250000, 80
number_cuts: 0

4. erstelle eine weitere Datei in dem Verzeichnis mit dem Namen "search_parameters.txt"
5. kopiere diesen Text in diese Datei:

nm_s20_l40
parameters [14]: 0.565877809513154 12.403630968062503 -3.287083667601104 148.252140701847225 22.653172650866729 0.605044182136812 -0.175903664911489 0.763281378859984 -1.353774447301647 178.780497083191449 23.791754933880959 1.187178866899705 -1.657198046562443 8.432537904620993
metadata: it: 12, ev: 603

6. Kopiere diese Datei in das Verzeichnis
7. starte die App (Doppelklick ist okay, läuft nur ein paar Sekunden)
8. Poste den Inhalt der erzeugten Dateien "out", "astronomy_checkpoint" sowie "stderr.txt"

Das ist übrigens der gleiche Typ der WUs, die jetzt immer fehlschlagen, nur viel kürzer.

Die korrekten Ergebnisse sehen so aus:

Zitat von out

nm_s20_l40
parameters [14]: 0.565877809513154 12.403630968062503 -3.287083667601104 148.252140701847220 22.653172650866729 0.605044182136812 -0.175903664911489 0.763281378859984 -1.353774447301647 178.780497083191450 23.791754933880959 1.187178866899705 -1.657198046562443 8.432537904620993
metadata: it: 12, ev: 603
fitness: -2.985299632582333
Gipsel_0.20_x64_SSE3: 0.20

Zitat von astronomy_checkpoint, nur zur Kontrolle

background_integral: 0.0004573799706103249
stream_integrals[2]: 10.01940558834422, 520.3371698804385
prob_sum: 1556.901212837737, num_zero: 0, bad_jacobians: 0
current_star_point: 105909
current_cut: 0
main_volume:
mu[min,max,steps,current_step]: 133, 249, 200, 0
nu[min,max,steps,current_step]: -1.25, 1.25, 80, 0
r[min,max,steps,current_step]: 16, 22.5, 200, 0
background_integral: 0.0004573799706103249
stream_integrals[2]: 10.01940558834422, 520.3371698804385
cuts: 0

Wenn das da steht, rechnet die App mit _2s-WUs auch auf Deiner CPU erstmal richtig.