Workunits (allgemein)

[thorsam]

um neue cmsearch WU zu generieren bräuchte rna world allerdings etwas mehr rechenpower unter linux x64.

Ich habe mal meinen 2600K mit 16 GB RAM angemeldet, falls noch Bedarf besteht?

Gruß thorsam

 

[East_Clintwood]

Zwei nette Brummer für "normale" WU´s 8)

.rnaworld.de/rnaworld/workunit.php?wuid=5010433
Rechnet schon 72 Stunden und will noch 25 weitere haben

.rnaworld.de/rnaworld/workunit.php?wuid=5038319
die is bei 32 fertigen und 32 verbleibenen Stunden

Bin mal gespannt wieviel MB Upload die haben werden. Vielleicht schaffts ja die größere der beiden über 50 MB zu kommen.
Rekord war bisher 24~ MB Upload für eine WU

 

[orpheus2k]

Vermutlich hat die Superlink Parallelrechnung zu einem Speichermangel geführt?

Michael

In dem System stecken 12GB und bisher hatte ich nie mehr als 2,5-3GB benötigt (also 2 Intron + 4 Superlink). Bei Superlink kann ich keine einzige fehlerhafte WU finden.
Gibt es schon eine Lösung für diese Speicherpeaks? Es ist sehr schade im die viele Rechenzeit

 

[Michael H.W. Weber]

In dem System stecken 12GB und bisher hatte ich nie mehr als 2,5-3GB benötigt (also 2 Intron + 4 Superlink).

Also, dass Du bei zwei parallelen Introns nur 3 GB als Peak-Bedarf animmst, halte ich zumindest für gewagt. Wieviel Speicher schnappt Superlink sich denn so im Schnitt?

Michael.

 

[orpheus2k]

Superlink benötigt 300-500 MB
Die beiden Introns lagen jeweils bei ca 800 MB
Macht zusammen 2,8-3,6 GB RAM!

 

[Michael H.W. Weber]

Superlink benötigt 300-500 MB
Die beiden Introns lagen jeweils bei ca 800 MB
Macht zusammen 2,8-3,6 GB RAM!

Ich denke, Du verwechselst da den aktuell benötigten Speicher (da kommen Deine 800 MB pro Intron WU gut hin) mit dem von mir gemeinten Maximal-RAM-Bedarf (und der liegt bei bis zu 3 GB pro WU).

Michael.

 

[orpheus2k]

Klar gibt es da den Unterschied zwischen aktueller Speichernutzung und dem maximalen Speicherpeak.
Ich hatte gehofft, dass meine 12GB RAM diese Peaks abfangen können.
Wenn 4 Superlink WUs je ca. 500MB benötigen, bleiben immerhin noch 10GB für 2 Intron WUs + virtuellem Speicher!
Ich kann es nun nicht mehr nachvollziehen und damit muss nun gut sein. Schade drum...

 

[Norman_RKN]

die introns sollten nun bei allen gekillt worden sein /durch das projekt/ und credits auf dem konto sein.
diese werden unter XXL erneut ausgegeben.
nun wird erstmal die richtige sortierung kurz und lang vorgenommen (S/XXL) wie es auch sein sollte.

 

[orpheus2k]

Ich habe RNA bei mir eigentlich auslaufen lassen.
Nun muss ich bemerken, dass die beiden Introns immer noch weiterlaufen.
Ich kann sie sicher abbrechen...

 

[heimbuec]

Kann es sein, dass aktuelle CMS S WUs einen Kern belegen und BOINC hindern, die anderen Kerne zu nutzen? Hab grade das Problem auf zwei Rechnern (X4 und X6).
Hier laufen lange RNA-Wutzen - pro Rechner eine - und obwohl von anderen Projekten Arbeit auf den Rechnern liegt, wird nur diese eine RNA-WU bearbeitet (also nur ein Kern genutzt). Alles andere (außer den GPU-Wutzen) wird verdrängt.
Screen:

 

[Norman_RKN]

mmh, wenn zu wenig freier RAM verfügbar ist kann dieses phänomen auftreten, aber ich glaube nicht dass diese WU so viel RAM abverlangt.
was steht denn in den eigenschaften der WU an gefordertem RAM ?

 

[heimbuec]

Bei installierten 8 GB (X4) bzw. 16 GB (X6) sollte doch eigentlich genug RAM da sein.
Eigenschaften der WU des X6:


RAM-Auslastung steht bei knapp 40%
.
EDIT :
.
Jetzt hat sich beim X6 eine POEM-WU dazugesellt. Sind aber immer noch 4 Kerne ohne Beschäftigung.

.
EDIT :
.
Kann es daran liegen, dass MW jetzt mehr Prozessorleistung für sich beansprucht?

Screen mit Task-Manager:


Eigentlich nicht. Ich hab MW mal angehalten und es gibt keinerlei Änderung!

 

[Norman_RKN]

komisch, da scheint boinc zu zicken.
in den settings 100% auslastung der kerne aktiviert etc. ?
ncpus eintrag evtl. in cc_config probiert (notlösung) und konfigdatei neu eingelesen ?

<cc_config>
<log_flags>
</log_flags>
<options>
<ncpus>6</ncpus>
</options>
</cc_config>

projekte mal nacheinander angehalten und dann geschaut was passiert ?
usw.

 

[heimbuec]

Ich wollte die Projekte (zumindest RNA) nicht anhalten, werd ich aber ausprobieren. An der Rechner-Konfig wurde nix verändert. Gestern hats ja noch geklappt.
.
EDIT :
.
Nachdem ich alles Projekte angehalten habe, saugt der PC sich RNA-WUS und schraubt die Anzahl der Tasks auf 6
Merkwürdig.
.
EDIT :
.
Methode klappt beim zweiten Rechner auch.

 

[Norman_RKN]

der verbugte boinc bekommt halt nix mit

 

[heimbuec]

Jetzt (19:19) läuft wieder nur ein Kern - trotz vorhandener RNA-WUs Und es ist wieder die Wutze mit den angepeilten 100 h!
.
EDIT :
.
Zweiter Rechner das gleiche Problem. Ich werde die Kisten wohl mal neu starten müssen (liegen ja auch Windows-Updates an).

Wenn's an RNA liegt, wär's Mist. Dann überlege ich ernsthaft, ob ich vor den angepeilten 500.000 Credits aus dem Projekt aussteige.

 

[Norman_RKN]

ich denke du hast viele projekte gleichzeitig am laufen und irgendwie kommt boinc da durcheinander.
probiere mal ein oder mehrere projekte kurz zu pausieren und schau was passiert.
wenn alle stricke reißen brich die 100h wutze ab bzw. pausiere sie mal.

 

[heimbuec]

Eigentlich laufen beide PCs seit Wochen stabil mit den vielen Projekten. Das Problem liegt erst seit heite Morgen an.

 

[heimbuec]

Der eine Rechner hat die Wutze erledigt und läuft wieder normal. Alle Kerne beschäftigt.
Mal sehen, ob sich das beim zweiten Rechner auch so erledigt.

 

[heimbuec]

Ich bin denn mal weg. Mir ist das Gehampel mit den WUs zu doof. RNA ist ein tolles PRojekt mit einem tollen Support hier im Forum - aber die Betreuung auf den einzelnen PCs stresst mich persönlich zu sehr.

 

[orpheus2k]

Ich denke das Problem liegt auch zum Teil beim BoincManager und dem Scheduler.
Ein ähnliches Problem hatte ich auch schon, nur dass bei mir mehr WUs als Kerne berechnet wurden, da die alten WUs nicht richtig pausiert wurden.

 

[East_Clintwood]

Hätt da mal ne Frage, kann man die WU´s wenn diese fertig berechnet wurden nicht wieder "zippen" oder würde das dann euren Server zu sehr stressen all diese WU´s wieder zu entpacken?
Hab hier nur DSL light da dauert so´n Upload wie in meinem Beispiel unten gern mal ne Stunde... kein Witz.
Klar ich könnte meinem Router sagen, nicht mehr dem Downstream vorrang zu gewähren, aber sehr viel schneller würd das dann auch nicht werden....
zB diese WU hat 26,01 MB Upload : ".rnaworld.de/rnaworld/workunit.php?wuid=5061706"

Dann noch was, wie lange kommt das noch vor das WU´s in nicht unerheblicher Menge vom Projekt abgebrochen werden?
Hab jetzt meinen Arbeispuffer von 2 auf 0,2 Tage gestellt um unnötigen Traffic weitestgehen zu vermeiden.

EDIT: meine Kiste bekommt seit 4Stunden 50 min keine WU´s mehr......

RechnerID: 10135

 

[Norman_RKN]

selbstverständlich sind die WU zipped sonst würde der upload bis zu 200+MB erreichen !
die WU werden nur abgebrochen wenn sie schon erfolgreich zurückgeliefert worden sind und validiert und noch nicht begonnen haben zu rechnen.
nochmal unnötig rechnen muss also nicht sein und kostet energie.
der server zickt im moment arg mit der verteilung der WU und ein zu kleiner buffer könnte leerlauf bedeuten im moment.

 

[dawe]

Also ich muss sagen außer das ab und an keine WU's kommen (dazu hab ich andere Projekte als Backup) habe ich keine Probleme mehr mit dem Projekt, auf meinen beiden Rechnern (x4, Linux, 4GB Ram + x6, Windows, 8 GB Ram) läuft alles ohne Probleme. Mein Mitbewohner hat sich einmal beschwert, dass er Probleme mit Starcraft 2 hatte, wo er mal wieder Nachts gezockt hat, war aber nur einmalig, hab den up und download mal eingeschränkt, aber bei Unitymedia sollte das dennoch reichen, nur wenn er grade die ganze Leitung nutzen will führt das bei den anderen natürlich zu Problemen.
Aber Wartungstechnisch ... auf die Linuxkiste schau ich einmal am Tag mit VNC ob alles okay ist und sonst läuft das von alleine ...

 

[Michael H.W. Weber]

Mal ganz kurz: Mich wundert es doch sehr, dass es momentan angeblich überhaupt noch Probleme mit dem Projekt geben soll.

Weder gibt es noch WUs mit überlangen Laufzeiten, noch solche mit überdimensioniertem RAM-Anspruch. Und es ist ja landläufig bekannt, dass wir zur vollständigen Umstellung auf das "Zwei-Versionen-CMSEARCH"-System (übrigens euch zu liebe aufgebaut, um euch mehr Flexibilität bei der Auswahl von Laufzeit und RAM-Anspruch zu ermöglichen), das aktuelle Material komplett durch- und letztlich auslaufen lassen müssen, um die Datenbanken zu leeren. Dies ist die vorübergehende Ursache dafür, dass momentan etwas spärlich WUs ausgegeben werden. Wir tun all dies auch in der Hoffnung, dieses Jahr am Pentathlon teilnehmen zu können. Wir haben dazu zudem unseren Server massiv umgebaut, sodass die Minisimulationen zur Laufzeitvorhersage weit im Vorfeld und auch noch auf einer separaten Maschine laufen. Wir haben die sehr kleinen WUs nun in gebündelter Form im Angebot, was die Serveranfragelast dramatisch reduziert und somit eine erhebliche Gesamtstabilisierung des Projekts bei großem Ansturm zur Folge hat. Als kleiner Nebeneffekt sind zusätzlich Pseudocheckpoints in diesen WUs implementiert.
Zu guter letzt kann ich im Vorfeld schon mal verraten, dass wir mehrere hochinteressante Serien neuer WUs bereits auf dem Server in der Warteschlange haben, von deren Ergebnissen ich mir sehr wichtige, medizinisch relevante Erkenntnisse in Sachen Viren erhoffe.

Da fragt man sich natürlich, was ihr denn noch wollt?

Ich denke, wir haben alles in die Waagschale geworfen, was möglich ist und wenn es jetzt noch irgendwo hakt, dann bitte wie bislang auch bei uns melden und ggf. mal die Maschine neu starten. Irgendwo fand ich neulich einen Forenbeitrag, wo jemand sich beklagte, es würde nur ein Kern ausgelastet, obwohl zwei RNA World WUs im BOINC-Manager als laufend angezeigt würden. Hatte ich auch das Problem und die Ursache war ein mit 50+ Tabs geöffneter Firefox und ein VISTA-System, dass seit zwei Wochen mit kontinuierlich geöffnetem Browser bestenfalls in den Ruhezustand versetzt wurde. Sorry, Leute, aber wie Bill Gates ja gegenüber Steve Jobs immer schon zugegeben hat: MS macht nicht die besten Produkte, aber das ist auch nicht nötig, solange es diejenigen sind, die sich am breitesten verticken lassen.

Michael.