GPUGRID (Ex-PS3GRID)
- Ersteller manni.deutsch
- Erstellt am
woever
Fleet Captain Special
Das ganze Problem ist doch sicher vermeidbar, laut Forum soll man nun downgraden. Irgendwann muss doch die Betaphase mal enden?! Das verdirbt einem den ganzen Spaß, immerzu muss man schauen obs richtig läuft.
Na ja, jetzt werden wieder WUs runtergeladen. GDF hat den wert für die benötigten GFlos der WU um den Faktor 10 vermindert.
Das sieht mir alles sehr unprofessionell und hektisch aus. Und das bei einem wissenschaftlichen Institut.
"Wissenschaftliche Institute" (sprich: Uni's) sind immer unprofessionell. Ansonsten würden wir hier Verträge und SLAs haben. Von Qualitätssicherung und Prozessen haben die meisten Universitäten zwar schon gehört, sich dann aber entschieden, aus Kostengründen drauf zu scheissen (wenn ich das mal so formulieren darf).
Und ja, selbst mit den Aussetzern gibt es hier AFAIK mehr Credits als in irgend einem anderen Projekt
Und wieso ersetzt das komische Programm hier meinen völlig normalen ASCII-Smiley mit so 'ner komischen blauen Kuller. Kann man das escapen?
Und ja, selbst mit den Aussetzern gibt es hier AFAIK mehr Credits als in irgend einem anderen Projekt
Und wieso ersetzt das komische Programm hier meinen völlig normalen ASCII-Smiley mit so 'ner komischen blauen Kuller. Kann man das escapen?
woever
Fleet Captain Special
Es gibt die Version 6.5.0 con BOINC ..... mit neunen Überraschungen-
Der CPU-Anteil von GPUGRID ist jetzt auch 0,04 und es werden auch wieder neben GBPUGRID bei quadro-CPUs 4 Tasks gestartet. Ich habe meine Gesamt-Cpuleistung darauf wieder auf 99% gestellt.
Irgendwie ernniert mich das an die Sinuskurve. Ich weiß nur immer nicht, ob wir oben oder unten sind bei einer neuene Version.
Der CPU-Anteil von GPUGRID ist jetzt auch 0,04 und es werden auch wieder neben GBPUGRID bei quadro-CPUs 4 Tasks gestartet. Ich habe meine Gesamt-Cpuleistung darauf wieder auf 99% gestellt.
Irgendwie ernniert mich das an die Sinuskurve. Ich weiß nur immer nicht, ob wir oben oder unten sind bei einer neuene Version.
Pr1nCe$$ FiFi
Grand Admiral Special
Jo, das darfst du so formulieren. Aber wenn du nochmal ein Plural-S mit einem Apostroph abtrennst, komme ich persönlich durch den Bildschirm gesprungen und zwinge dich, die #'-Taste zu fressen. 8)
Na ja, jetzt werden wieder WUs runtergeladen. GDF hat den wert für die benötigten GFlos der WU um den Faktor 10 vermindert.
Das sieht mir alles sehr unprofessionell und hektisch aus. Und das bei einem wissenschaftlichen Institut.
Was sind denn GFlos? Welchen Wert? Bitte erklären. Danke.
.
EDIT :
.
Gute Idee. Ich bin auch für die Erhöhung der Rechtschreibe-Frequenz.
Hier, ich hab noch ein paar "Abstrophen" übrig:"'''''''''".
woever
Fleet Captain Special
Was sind denn GFlos? Welchen Wert? Bitte erklären. Danke.
.
EDIT :
.
Gute Idee. Ich bin auch für die Erhöhung der Rechtschreibe-Frequenz.
Hier, ich hab noch ein paar "Abstrophen" übrig:"'''''''''".
Das war ein Schreibfehler sollte GFLOPS sein.
Hier der Originaltext:
I have reduced the number of flops requested by a factor 10 on type of workunits.
To see if things improve.
gdf
Zuletzt bearbeitet:
Mein Hirn sagt mir, dass die Units dann länger brauchen.
Das Programm selbst braucht nach wievor mehr als einen halben CPU-Kern.
Wie kann man denn Flops anfragen? Sowas kann man doch nicht regulieren, man kann doch nur die Rechenzeit einschränken. Die bekommen das nie hin, da wette ich mein linkes Ei.
Edit:
Der Einbruch des unsrigen Outputs sagt alles. Das ist eine sensationelle Unfähigkeit die hier an den Tag gelegt wird seitens der Projektbetreiber.
Edit:
Der Server ist down.
Und folgende Einstellung sollten wieder für mehr Workunits sorgen:
in client_state.xml
bei gpugrid
Code:
<nrpc_failures>0</nrpc_failures>
<master_fetch_failures>0</master_fetch_failures>
<duration_correction_factor>1.000000</duration_correction_factor>
Zuletzt bearbeitet:
Und folgende Einstellung sollten wieder für mehr Workunits sorgen: in client_state.xml bei gpugrid [code schrieb:
Naja, bei mir hat's kurz geholfen, die nächsten WUs waren dann wieder mit "high estimate".
Das Projekt ist momentan depositatum de latrina. Ich lasse jetzt die WUs, die ich habe, durchlaufen und schalte dann morgen früh alles für zwei Wochen ab. Vielleicht sieht es im neuen Jahr dann besser aus.
Hehe, das wirft uns aber im Projekt zurück, so kommen wir nie an die Spitze!
Der andre Weg ist, immerzu diese Werte in der Datei zu korregieren. Man könnte das auch von einem Daemon machen lassen. Wer schreibt schnell mal einen?
heimbuec
Grand Admiral Special
Läuft aber irgendwie nur sporadisch. Ich hab jetzt schon 2 Tage durch, an denen keine WUs kamen.
heavy-Ions@boinc
Grand Admiral Special
- Mitglied seit
- 03.10.2007
- Beiträge
- 3.405
- Renomée
- 23
bei mir läuft es noch nicht. einer meiner kisten hat seit gestern schon keine WUs mehr bekommen, die andere kiste läuft in ein paar stunden leer.
heavy-Ions@boinc
Grand Admiral Special
- Mitglied seit
- 03.10.2007
- Beiträge
- 3.405
- Renomée
- 23
ja, aktualisiert, resettet, auf 6.4.2 geupdatetd, alles schon probiert.
die WU die ich noch habe hat eine irrwitzig hohe "time to complete" verhersage von über 500h deshalb blockiert mir gpugris auch fast meine anderen projekte, da sie keinen bunker ordern.
die WU die ich noch habe hat eine irrwitzig hohe "time to complete" verhersage von über 500h deshalb blockiert mir gpugris auch fast meine anderen projekte, da sie keinen bunker ordern.
in der client_state.xml sind korrektur-werte, diese musst du auf 1 setzen, wie weiter oben beschrieben
heavy-Ions@boinc
Grand Admiral Special
- Mitglied seit
- 03.10.2007
- Beiträge
- 3.405
- Renomée
- 23
Auch schon probiert
auch keine Hilfe.
auch keine Hilfe.
koschi
Grand Admiral Special
Seltsam... Und sonst testweise mal ne parallele BOINC Installation aufsetzen?
In der Hostübersicht werden jetzt auch die Coprozessorn mit angezeigt (sofern vorhanden):
http://www.gpugrid.net/show_host_detail.php?hostid=6998
Außerdem scheint es in der Linux-App n memoryleak zu geben, so dass der Speicherverbrauch mit zunehmender Laufzeit enorm zunimmt. Ich war heute morgen schon bei 1.2GB nur für den acemd Prozess...
In der Hostübersicht werden jetzt auch die Coprozessorn mit angezeigt (sofern vorhanden):
http://www.gpugrid.net/show_host_detail.php?hostid=6998
Außerdem scheint es in der Linux-App n memoryleak zu geben, so dass der Speicherverbrauch mit zunehmender Laufzeit enorm zunimmt. Ich war heute morgen schon bei 1.2GB nur für den acemd Prozess...
heavy-Ions@boinc
Grand Admiral Special
- Mitglied seit
- 03.10.2007
- Beiträge
- 3.405
- Renomée
- 23
ha! geht jetzt. hatte gpu und alle anderen projekte angehalten, alle bis auf gpu auf "no new work" und dann gpu aktualisiert, dann ging es.
die neuen WU haben auch nicht mehr diese irrsinnig hohen cpu-zeiten im manager.
die neuen WU haben auch nicht mehr diese irrsinnig hohen cpu-zeiten im manager.
heimbuec
Grand Admiral Special
Wie kann man denn SETI dazu bringen nur GPU-WUs zu bekommen??
heimbuec
Grand Admiral Special
Das klappt bei mir auch so. Ist nur doof, dass man anscheinend 2 bis 3-mal am Tag so verfahren muss.
