GPUGRID

Analyse und Vorhersage von Struktur und Faltungsweg (Folding@home, GPUGRID, Rosetta@home, ...)
Nachricht
Autor
Benutzeravatar
gemini8
Vereinsmitglied
Vereinsmitglied
Beiträge: 4728
Registriert: 31.05.2011 10:30
Wohnort: Hannover

Re: GPUGRID

#325 Ungelesener Beitrag von gemini8 » 27.11.2021 20:57

Server ist voll; bedient euch!
Gruß, Jens
- - - - - -
Lowend-User und Teilzeitcruncher

Bild Bild Bild
Bild

Benutzeravatar
Kolossus
TuX-omane
TuX-omane
Beiträge: 3443
Registriert: 26.10.2014 14:51
Wohnort: Köln
Kontaktdaten:

Re: GPUGRID

#326 Ungelesener Beitrag von Kolossus » 27.11.2021 21:06

Vielmals merci
Gruß Harald

Niveau ist keine Creme....


Bild

Benutzeravatar
Uwe-Bergstedt
Mikrocruncher
Mikrocruncher
Beiträge: 16
Registriert: 24.11.2021 19:52

Re: GPUGRID

#327 Ungelesener Beitrag von Uwe-Bergstedt » 27.11.2021 22:08

:uhoh: :bad: :evil: das war wohl nix: nach 6Sec ist Schluß---<message>
(unknown error) - exit code 195 (0xc3)</message>

https://www.gpugrid.net/result.php?resultid=32706442

Benutzeravatar
gemini8
Vereinsmitglied
Vereinsmitglied
Beiträge: 4728
Registriert: 31.05.2011 10:30
Wohnort: Hannover

Re: GPUGRID

#328 Ungelesener Beitrag von gemini8 » 28.11.2021 07:43

Einer meiner Rechner hat am 24. und 25. lauter Fehler nach ca. 35 bis 40 Sekunden geworfen, macht jetzt aber wieder anstandslos mit.
Sah so aus:

Code: Alles auswählen

<core_client_version>7.14.2</core_client_version>
<![CDATA[
<message>
process exited with code 195 (0xc3, -61)</message>
<stderr_txt>
06:01:30 (9422): wrapper (7.7.26016): starting
06:01:49 (9422): wrapper (7.7.26016): starting
06:01:49 (9422): wrapper: running bin/acemd3 (--boinc --device 0)
ACEMD failed:
    Particle coordinate is nan
06:02:03 (9422): bin/acemd3 exited; CPU time 8.652714
06:02:03 (9422): app exit status: 0x1
06:02:03 (9422): called boinc_finish(195)

</stderr_txt>
]]>
Bei dir sieht das anders aus:

Code: Alles auswählen

<core_client_version>7.16.20</core_client_version>
<![CDATA[
<message>
(unknown error) - exit code 195 (0xc3)</message>
<stderr_txt>
22:00:20 (12708): wrapper (7.9.26016): starting
22:00:20 (12708): wrapper: running bin/acemd3.exe (--boinc --device 0)
22:00:21 (12708): bin/acemd3.exe exited; CPU time 0.000000
22:00:21 (12708): app exit status: 0xc0000135
22:00:21 (12708): called boinc_finish(195)
0 bytes in 0 Free Blocks.
296 bytes in 4 Normal Blocks.
1144 bytes in 1 CRT Blocks.
0 bytes in 0 Ignore Blocks.
0 bytes in 0 Client Blocks.
Largest number used: 0 bytes.
Total allocations: 154078 bytes.
Dumping objects ->
{321029} normal block at 0x0000026650055890, 140 bytes long.
 Data: <<project_prefere> 3C 70 72 6F 6A 65 63 74 5F 70 72 65 66 65 72 65 
..\api\boinc_api.cpp(309) : {321026} normal block at 0x0000026650019F90, 8 bytes long.
 Data: <  &#173;Qf   > 00 00 AD 51 66 02 00 00 
{320389} normal block at 0x0000026650055070, 140 bytes long.
 Data: <<project_prefere> 3C 70 72 6F 6A 65 63 74 5F 70 72 65 66 65 72 65 
{319783} normal block at 0x0000026650019950, 8 bytes long.
 Data: < | Pf   > 20 7C 04 50 66 02 00 00 
..\zip\boinc_zip.cpp(122) : {151} normal block at 0x00000266500239F0, 260 bytes long.
 Data: <                > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
{135} normal block at 0x000002665001FA10, 32 bytes long.
 Data: <windows_x86_64__> 77 69 6E 64 6F 77 73 5F 78 38 36 5F 36 34 5F 5F 
{134} normal block at 0x0000026650019FE0, 16 bytes long.
 Data: <&#192;&#223; Pf           > C0 DF 01 50 66 02 00 00 00 00 00 00 00 00 00 00 
{133} normal block at 0x000002665001DFC0, 40 bytes long.
 Data: <&#224;&#159; Pf    &#250; Pf   > E0 9F 01 50 66 02 00 00 10 FA 01 50 66 02 00 00 
{124} normal block at 0x000002665001DF50, 48 bytes long.
 Data: <--boinc --device> 2D 2D 62 6F 69 6E 63 20 2D 2D 64 65 76 69 63 65 
{123} normal block at 0x000002665001A210, 16 bytes long.
 Data: <&#232;H Pf           > E8 48 02 50 66 02 00 00 00 00 00 00 00 00 00 00 
{122} normal block at 0x0000026650019C20, 16 bytes long.
 Data: <&#192;H Pf           > C0 48 02 50 66 02 00 00 00 00 00 00 00 00 00 00 
{121} normal block at 0x000002665001A1C0, 16 bytes long.
 Data: < H Pf           > 98 48 02 50 66 02 00 00 00 00 00 00 00 00 00 00 
{120} normal block at 0x000002665001A120, 16 bytes long.
 Data: <pH Pf           > 70 48 02 50 66 02 00 00 00 00 00 00 00 00 00 00 
{119} normal block at 0x000002665001A5D0, 16 bytes long.
 Data: <HH Pf           > 48 48 02 50 66 02 00 00 00 00 00 00 00 00 00 00 
{118} normal block at 0x0000026650019B80, 16 bytes long.
 Data: < H Pf           > 20 48 02 50 66 02 00 00 00 00 00 00 00 00 00 00 
{117} normal block at 0x000002665001A260, 16 bytes long.
 Data: < H Pf           > 00 48 02 50 66 02 00 00 00 00 00 00 00 00 00 00 
{116} normal block at 0x000002665001A4E0, 16 bytes long.
 Data: <&#216;G Pf           > D8 47 02 50 66 02 00 00 00 00 00 00 00 00 00 00 
{115} normal block at 0x000002665001A030, 16 bytes long.
 Data: <&#176;G Pf           > B0 47 02 50 66 02 00 00 00 00 00 00 00 00 00 00 
{114} normal block at 0x00000266500247B0, 496 bytes long.
 Data: <0&#160; Pf   bin/acem> 30 A0 01 50 66 02 00 00 62 69 6E 2F 61 63 65 6D 
{64} normal block at 0x0000026650019B30, 16 bytes long.
 Data: < &#234;pP&#246;           > 80 EA 70 50 F6 7F 00 00 00 00 00 00 00 00 00 00 
{63} normal block at 0x000002665001A6C0, 16 bytes long.
 Data: <@&#233;pP&#246;           > 40 E9 70 50 F6 7F 00 00 00 00 00 00 00 00 00 00 
{62} normal block at 0x0000026650019860, 16 bytes long.
 Data: <&#248;WmP&#246;           > F8 57 6D 50 F6 7F 00 00 00 00 00 00 00 00 00 00 
{61} normal block at 0x0000026650019D60, 16 bytes long.
 Data: <&#216;WmP&#246;           > D8 57 6D 50 F6 7F 00 00 00 00 00 00 00 00 00 00 
{60} normal block at 0x0000026650019E00, 16 bytes long.
 Data: <P mP&#246;           > 50 04 6D 50 F6 7F 00 00 00 00 00 00 00 00 00 00 
{59} normal block at 0x0000026650019A40, 16 bytes long.
 Data: <0 mP&#246;           > 30 04 6D 50 F6 7F 00 00 00 00 00 00 00 00 00 00 
{58} normal block at 0x0000026650019900, 16 bytes long.
 Data: <&#224; mP&#246;           > E0 02 6D 50 F6 7F 00 00 00 00 00 00 00 00 00 00 
{57} normal block at 0x000002665001A670, 16 bytes long.
 Data: <  mP&#246;           > 10 04 6D 50 F6 7F 00 00 00 00 00 00 00 00 00 00 
{56} normal block at 0x000002665001A3A0, 16 bytes long.
 Data: <p mP&#246;           > 70 04 6D 50 F6 7F 00 00 00 00 00 00 00 00 00 00 
{55} normal block at 0x00000266500199F0, 16 bytes long.
 Data: < &#192;kP&#246;           > 18 C0 6B 50 F6 7F 00 00 00 00 00 00 00 00 00 00 
Object dump complete.

</stderr_txt>
]]>
Ich habe leider keine Ahnung davon, was uns diese Litanei sagen soll. :biggrin2:
Gruß, Jens
- - - - - -
Lowend-User und Teilzeitcruncher

Bild Bild Bild
Bild

Benutzeravatar
gemini8
Vereinsmitglied
Vereinsmitglied
Beiträge: 4728
Registriert: 31.05.2011 10:30
Wohnort: Hannover

Re: GPUGRID

#329 Ungelesener Beitrag von gemini8 » 28.11.2021 07:45

Btw.: Das Serverzertifikat ist ausgelaufen.
Mag sein, dass wir unsere Aufgaben weder zurückgeben, noch neue ziehen können.
Gruß, Jens
- - - - - -
Lowend-User und Teilzeitcruncher

Bild Bild Bild
Bild

Benutzeravatar
Kolossus
TuX-omane
TuX-omane
Beiträge: 3443
Registriert: 26.10.2014 14:51
Wohnort: Köln
Kontaktdaten:

Re: GPUGRID

#330 Ungelesener Beitrag von Kolossus » 28.11.2021 12:05

Nein, kein Serverzertifikat aus gelaufen,
die 101 WUs machen Probleme. 1121 laufen. Da gab es schonmal ein Thread hier im Forum. Klickedickack
Gruß Harald

Niveau ist keine Creme....


Bild

Benutzeravatar
Michael H.W. Weber
Vereinsvorstand
Vereinsvorstand
Beiträge: 21536
Registriert: 07.01.2002 01:00
Wohnort: Marpurk
Kontaktdaten:

Re: GPUGRID

#331 Ungelesener Beitrag von Michael H.W. Weber » 28.11.2021 12:24

Von der Teilnahme an dem Projekt kann ich derzeit nur abraten: Selbst wenn man das obige Problem händisch korrigiert hat, nimmt der Server keine WUs mit mehr als 500 MB Ergebnisdateigröße an, schrottet diese einfach ab und trägt somit einzig zur Produktion heißer Luft bei.
Die Projektleitung ist durch etliche Forenbeiträge vor Wochen auf das Problem hingewiesen worden, macht aber keine mir bekannt gewordenen Anstalten, das Problem zu beheben.
So lange deren Kommunikation derartig schlecht läuft, spendiere ich meine Rechenzeit lieber anderen Projekten - was sehr, sehr schade ist, da GPUGRID gewiss zu einem der innovativsten und auch interessantesten DC-Projekte gehört.

Michael.

P.S.: Vielleicht schreibt ja mal jemand dem Gianni de Fabritiis direkt eine eMail und bittet um einen offiziellen Kommentar dazu.
Fördern, kooperieren und konstruieren statt fordern, konkurrieren und konsumieren.

http://signature.statseb.fr I: Kaputte Seite A
http://signature.statseb.fr II: Kaputte Seite B

Bild Bild Bild

Jürgen
Projekt-Fetischist
Projekt-Fetischist
Beiträge: 647
Registriert: 05.09.2001 01:00
Wohnort: Porta Westfalica
Kontaktdaten:

Re: GPUGRID

#332 Ungelesener Beitrag von Jürgen » 28.11.2021 23:37

Ich hatte auch (unbemerkt) eine WU von dem Projekt am Laufen, eine "Cuda101". Die wurde auch problemlos durchgerechnet.
Aber sie wird aktuell nicht hochgeladen (aktuelle Projektverzögerung 2 Stunden".
Im Log vom BM finden sich folgende Einträge (allerdings bin ich nicht ganz sicher, ob die zu GpuGrid gehören, da kein Projekt angegeben):

Code: Alles auswählen

So 28 Nov 2021 19:03:09 CET |  | Project communication failed: attempting access to reference site
So 28 Nov 2021 19:03:11 CET |  | Internet access OK - project servers may be temporarily down.
Wenn ich die Webseite aufrufe, erhalte ich einen Zertifikatsfehler.
Jürgen
-----
Der Computer ist ein Hilfsmittel zum Lösen von Problemen, die man ohne ihn gar nicht erst hat!
Bild Bild

Benutzeravatar
Michael H.W. Weber
Vereinsvorstand
Vereinsvorstand
Beiträge: 21536
Registriert: 07.01.2002 01:00
Wohnort: Marpurk
Kontaktdaten:

Re: GPUGRID

#333 Ungelesener Beitrag von Michael H.W. Weber » 29.11.2021 00:51

Ja, da war neben den anderen Problemen auch im Forum bei GPUGRID erneut wieder die Rede von einem Zertifikatsproblem.

Michael.
Fördern, kooperieren und konstruieren statt fordern, konkurrieren und konsumieren.

http://signature.statseb.fr I: Kaputte Seite A
http://signature.statseb.fr II: Kaputte Seite B

Bild Bild Bild

Benutzeravatar
gemini8
Vereinsmitglied
Vereinsmitglied
Beiträge: 4728
Registriert: 31.05.2011 10:30
Wohnort: Hannover

Re: GPUGRID

#334 Ungelesener Beitrag von gemini8 » 29.11.2021 07:46

Hochladen wird erst möglich sein, wenn das Problem behoben ist.
Bis dahin bleiben die Aufgaben unten.
Wie es mit Validierung aussieht, weiß man nicht, weil ich dem Projekt zutraue, die Deadlines nicht zu verlängern, bevor das neue Zertifikat eingespielt wird.
Falls sie daran denken sollten, würde ich dann immer noch um den Bonus für schnelle Rückgabe bangen.
Also mal wieder alles ganz toll! :biggrin2:
Gruß, Jens
- - - - - -
Lowend-User und Teilzeitcruncher

Bild Bild Bild
Bild

Benutzeravatar
Michael H.W. Weber
Vereinsvorstand
Vereinsvorstand
Beiträge: 21536
Registriert: 07.01.2002 01:00
Wohnort: Marpurk
Kontaktdaten:

Re: GPUGRID

#335 Ungelesener Beitrag von Michael H.W. Weber » 29.11.2021 12:37

Zum Zertifikatsproblem: http://www.gpugrid.net/forum_thread.php ... true#57899
Mein Hinweis auf die Aufhebung/Anpassung des Uploadgdateigrößenlimits ist direkt das Posting darüber.
:roll:

Michael.

[edit]: Ich fand eben im GPUGRID-Forum eine Lösung für die Uploads während des Zertifikatproblems.
Fördern, kooperieren und konstruieren statt fordern, konkurrieren und konsumieren.

http://signature.statseb.fr I: Kaputte Seite A
http://signature.statseb.fr II: Kaputte Seite B

Bild Bild Bild

Jürgen
Projekt-Fetischist
Projekt-Fetischist
Beiträge: 647
Registriert: 05.09.2001 01:00
Wohnort: Porta Westfalica
Kontaktdaten:

Re: GPUGRID

#336 Ungelesener Beitrag von Jürgen » 29.11.2021 20:45

Meine noch offene WU wurde im Laufe des heutigen Tages hochgeladen und auch validiert - ca. 24h und 280k Punkte (etwas schneller als die, die ich in der Vergangenheit hatte)
Eine zweite, noch offene WU hat nach wie vor Abgabedatum 2. Dez, also bisher nicht verlängert.
Jürgen
-----
Der Computer ist ein Hilfsmittel zum Lösen von Problemen, die man ohne ihn gar nicht erst hat!
Bild Bild

Antworten

Zurück zu „Protein- und Nukleinsäureforschung“