RNA@home: P3D vs SETI.Germany

[Michael H.W. Weber]

Feeeertig die erste 3800 credits


ufffffff ...

Das ist astrein! Da soll noch einer sagen, unsere WUs seien kaputt.

Bezügl. maximalem RAM-Verbrauch: Die CMC Lin64f Intron_gpi braucht 2,8 GB.

Michael.

 

[oconner]

@Michael,
hehehe, deswegen sind ja auch noch 4Gbyte für den Intel bestellt, der jetzt auch unter Linux 64Bit läuft
auf dem wombat-desktop sind noch 3 große
rechts auf dem Bildschirm sieht man ganz gut die Speicherauslastung


Nachtrag, hätte ich ja fast vergessen

 

[denjo]

TOLL ! irgendwann wurden plötzlich 4 wus zerstört somit auch meine beiden monster 200 std rechenzeit und ziemliche viele credits dahin

 

[Michael H.W. Weber]

TOLL ! irgendwann wurden plötzlich 4 wus zerstört somit auch meine beiden monster 200 std rechenzeit und ziemliche viele credits dahin

Auf der Kiste mit 1GB RAM? Hatte ich befürchtet. Was mich wundert ist, dass Du auf der Maschine diese Brocken bekommen hast.

Michael.

 

[denjo]

ne daran lags nicht ram hatte er im übrigen 2 gb. das problem war ehr das ich ein spiel gestartet hatte und die vm nicht pausiert war.
während dessen hat er die wus gekillt

 

[Fränki´s Welle]

ne daran lags nicht ram hatte er im übrigen 2 gb. das problem war ehr das ich ein spiel gestartet hatte und die vm nicht pausiert war.
während dessen hat er die wus gekillt

Das Probem war nicht der Rechner sondern der pöse Benutzer.
Über 200 Stunden? Na da hast du dich ja gleich selber richtig extrem bestraft.

Leider bin ich nicht besser.

 

[JagDoc]

Diese: cms_GA[e30-50MB_Lin64f]_Danio-rerio-(zebrafish)_CU651621.lin.EMBL_RF00028_Intron_gpI_1284623755_2208
braucht 2,1GB, Laufzeit ca. 80 Stunden.

cu JagDoc

 

[Fränki´s Welle]

Habe hier eine WU die mit einer Fehlermeldung abgebrochen wurde.
ecms_GA[e30-50MB_Lin64f]_Ornithorhynchus-anatinus-(platypus)_CM000424.lin.EMBL_RF00028_Intron_gpI_1284623755_2233_7

stderr out

<core_client_version>6.10.18</core_client_version>
<![CDATA[
<message>
 - exit code 195 (0xc3)
</message>
<stderr_txt>
RNA World wrapper v0.04
wrapper: no checkpoint file found
wrapper: running unzip (-o graphics.zip)
wrapper: no checkpoint file found
wrapper: running unzip (-o in.zip)
wrapper: no checkpoint file found
wrapper: running unzip_cpufeat (cmsearch.zip)
wrapper: no checkpoint file found
wrapper: running cmsearch (--forecast 1  cmfile in)
forecast.txt found.
wrapper: no checkpoint file found
wrapper: running cmsearch (-o out  cmfile in)
forecast.txt found.
app exit status: 0x3
08:05:18 (1880): called boinc_finish

Die hat bis jetzt noch keiner berechnen können.
Ich habe mal bei den anderen Usern nachgeschaut die diese WU berechnen wollten. Es ist immer die selbe Fehlermeldung.
Huhu gruenmuckel Sylvester und species_0001. Euch hat es auch erwischt.
Unser App - Progamierer Gipsel versucht sich noch an der WU

Edit: Nun sind alle an dieser WU gescheitert
@Michael Gibt es nun doch defekte WUs?

 

[ICEMAN]

@Michael,
ich würde mir gern was wünschen, dass Checkpoints eingebaut werden und zwar in alle WUs.
Nicht jeder kann seine PCs 24h laufen lassen und wenn dann gerade eine WU mit 15h ansteht ist das mehr als ärgerlich, wenn man am nächsten Tag von vorne rechnen muss und abschießen will ich die WU auch nicht.

 

[gruenmuckel]

@Michael,
ich würde mir gern was wünschen, dass Checkpoints eingebaut werden und zwar in alle WUs.
Nicht jeder kann seine PCs 24h laufen lassen und wenn dann gerade eine WU mit 15h ansteht ist das mehr als ärgerlich, wenn man am nächsten Tag von vorne rechnen muss und abschießen will ich die WU auch nicht.

Da stimme ich dir zu, das muss Priorität haben.

 

[ceVoIX]

Juhu, übernacht die 50k erreicht

 

[area50]

Hab jetzt ne 65std WU unter WIndows bekommen, braucht aktuell 1GB Ram.

 

[Gast02102016]

Ich fahr schon mal rechts rüber, Indy und vor allem dem Kater seine Lichter tauchen im Rückspiegel auf. Nicht das die mir noch drauf brummen, bei dem Tempo..

 

[[MTB]JackTheRipper]

Es lässt sich leider nicht überall checkpointing einbauen, oder eventuell sehr kompliziert.
Da der Code wohl offen steht dürft ihr euch gerne versuchen

 

[Kater Sylvester]

@VC/HVH:
Keine Sorge. Ich hätte vor dem Überholen schon noch wild gehupt und die Lichthupe betätigt.

Sodele. Der letzte Rechner im Rack ist repariert. Damit sind nun alle Rechner am Start.
Noch einen Lüfter austauschen, dann kommt Cluster Node 29 auf den OP Tisch.
Ich hoffe, der crunched dann heute auch wieder mit.

 

[ICEMAN]

Es lässt sich leider nicht überall checkpointing einbauen, oder eventuell sehr kompliziert.
Da der Code wohl offen steht dürft ihr euch gerne versuchen

Wenn ich programmieren könnte, hätte ich mich schon lange daran gemacht

 

[orpheus2k]

@Fränki´s Welle

So eine hab ich hier auch wieder:
cms_GA[e30-50MB_Lin64f]_Danio-rerio-(zebrafish)_CU651622.lin.EMBL_RF00028_Intron_gpI_1284623755_2209

 

[Emploi]

Ich knall hier eine cmc nach der anderen Raus! Ist eigentlich noch jemand ohne Arbeit?
Laut Statistik sollte es ja jetzt genug für alle geben, quasi Vollbeschäftigung. 0

Also alle die noch nicht mit dabei sind, ran an die ...

​

​

...Knusperwurst ​

 

[Fränki´s Welle]

@Fränki´s Welle

So eine hab ich hier auch wieder:
cms_GA[e30-50MB_Lin64f]_Danio-rerio-(zebrafish)_CU651622.lin.EMBL_RF00028_Intron_gpI_1284623755_2209

Sieht nach der selben Fehlermeldung aus.

@Emploi Das heist Bulette.

 

[KGBerlin]

32 Stunden bei 6% und die Restzeit ist sinkend mit 67 Stunden angegeben?
Wie soll das denn gehen?
Und wo kommt die überhaupt her?

Ich hatte eigentlich alle mit über 6 Stunden angegebenen Wutzen abgebrochen
Also da gibts noch etwas zu verbessern am Beta.
Wieder ~60 Stunden rechnen fürn Ar***, die Dinger fliegen raus

 

[Michael H.W. Weber]

ne daran lags nicht ram hatte er im übrigen 2 gb. das problem war ehr das ich ein spiel gestartet hatte und die vm nicht pausiert war.
während dessen hat er die wus gekillt

Danke für die detaillierte Info.
Mal eine Frage: Gibt es irgendein Tool, dass den Speicherverlauf eines Tasks loggt und mir am Ende den Peakverbrauch anzeigt? Fall ja, müßte man so etwas mal auf möglichst vielen Maschinen laufen lassen und die Ergebnisse für alle CMS und CMC Tasks tabelliert sammeln. Auf der Datenbasis liesse sich dann eine viel genauere RAM-Vorhersage anstellen und damit wiederum die momenten auf einigen Maschinen auftretenden Probleme reduzieren oder gar komplett beheben.

32 Stunden bei 6% und die Restzeit ist sinkend mit 67 Stunden angegeben?
Wie soll das denn gehen?
Und wo kommt die überhaupt her?

Was war jetzt genau das Problem mit dieser WU? Und welche war es übehaupt?

Ich hatte eigentlich alle mit über 6 Stunden angegebenen Wutzen abgebrochen
Also da gibts noch etwas zu verbessern am Beta.
Wieder ~60 Stunden rechnen fürn Ar***, die Dinger fliegen raus

Außer Checkpointing und RAM-Vorhersage sehe ich da jetzt ehrlich gesagt keinen akuten Verbesserungsbedarf. Und mal am Rande zum Thema Beta: Dies sind keine Testläufe. Wir sind in Produktion. Ob da nun Beta draufsteht oder nicht. Hier werden anständige Ergebnisse erarbeitet. Und ab Morgen präsentieren wir wieder einmal Daten auf einer Fachkonferenz. Diesmal auf der 126. GDNÄ in Dresden.

Michael.

 

[oconner]

Morgen wird wieder eine fertig
Mittlerweile knapp 4Gbyte RAM in benutzung.

 

[Emploi]

... Und ab Morgen präsentieren wir wieder einmal Daten auf einer Fachkonferenz. Diesmal auf der 126. GDNÄ in Dresden.

Michael.

Wer spricht denn da wann? Beim kurzen Programmüberflug hab ich es nicht eindeutig gefunden. http://gdnae.de/media/pdf/GDNAE_GesamtProgramm_2010.pdf Oder läuft das nebenbei..?

 

[flybyray]

Mal eine Frage: Gibt es irgendein Tool, dass den Speicherverlauf eines Tasks loggt und mir am Ende den Peakverbrauch anzeigt? Fall ja, müßte man so etwas mal auf möglichst vielen Maschinen laufen lassen und die Ergebnisse für alle CMS und CMC Tasks tabelliert sammeln. Auf der Datenbasis liesse sich dann eine viel genauere RAM-Vorhersage anstellen und damit wiederum die momenten auf einigen Maschinen auftretenden Probleme reduzieren oder gar komplett beheben.

Mal eine Frage zurück! Wer Entwickelt denn da ohne solche Tools? Wird hier keine Komplexität berechnet (Abschätzung nach oben).

Außer Checkpointing und RAM-Vorhersage sehe ich da jetzt ehrlich gesagt keinen akuten Verbesserungsbedarf.

Nicht nur Speicher Vorhersage! Auch die Laufzeit sollte mal verbessert werden! Daher sollte man sich mal überlegen ob man das Ablaufdatum für WUs nicht erhöht! Ich bekomme da welche die beginnen gleich mit Aktiv, Hohe Priorität weil sie mit mehr als 120Stunden (eine sogar mit 230 Stunden) angegeben ist.
Ich habe diese auch abgebrochen und werde nach Beendigung der kleineren auch nicht mehr an dem Projekt teilnehmen.
Laufzeit und Speichervorhersagen sind so eines der wichtigsten Kriterien im High Performace Computing. Schade, ein bisschen mehr Ernsthaftigkeit!
PS: Da kann man nur hoffen, dass es bei der Qualität und dem Nutzen der berechneten Daten besser aussieht.

 

[stephan4520]

GDNÄ? in Dräsdn?