8. Pentathlon 2017 - LHC@home (Schwimmen)

Mein Laptop-i7 ist auch leer und bekommt nichts mehr. Habe auf Cosmo gewechselt.

Der FX hat noch Arbeit, der 1700X arbeitet an Cosmo und LHC (Restmenge)
 
:o ---- > Ja, dürfen die denn sowas? ???

Ich habe mir mit der Verkürzung dser Bunkereinstellungen auch keinen Gefallen getan.
Jetzt glaubt der BM, es reicht, die Wuzen hochzuladen, weil er keine neuen anfordern will, meint er,
die fertigen Wuzen auch nicht melden zu müssen.
*admin*

Heißt: Jetzt muss ich alle paar Stunden per Hand anstubsen. Na gut, ist eben so.
 
Also ich hab noch reichlich Arbeit- die aber nicht fertig wird. Mit 4GB Arbeitsspeicher auf dem PH2 x6 bleibt BOINC einfach stur mit "warte auf Speicher" stehen!! Es wird keine der Möglichen ca. 50 LHC Vbox64 Wu gerechnet. Das ist wirklich der letzte Dreck
 
Dann nimm nur die Sixtrack.
Hab mir auch schon zwei dicke Clients zerschossen, indem sämtlicher Speicher (Arbeitsspeicher, HDD, Swap) übergelaufen waren.
 
Also ich hab noch reichlich Arbeit- die aber nicht fertig wird. Mit 4GB Arbeitsspeicher auf dem PH2 x6 bleibt BOINC einfach stur mit "warte auf Speicher" stehen!! Es wird keine der Möglichen ca. 50 LHC Vbox64 Wu gerechnet. Das ist wirklich der letzte Dreck
Welche LHC Vbox? Bei 4GB funktionierte nur 1x Theory mit 1 Core
Code:
<app_config>
    <project_max_concurrent>6</project_max_concurrent>
    <app>
        <name>sixtrack</name>
        <max_concurrent>5</max_concurrent>
    </app>
    <app>
        <name>Theory</name>
        <max_concurrent>1</max_concurrent>
    </app>
</app_config>
 
Zuletzt bearbeitet:
Das Problem besteht doch nicht bei Cosmo sondern bei LHC ( bei cosmo hab die app_config in etwa so ) und die Speichereinstellungen passen auch. Die blöde Kiste hat ja auch schon mal mit einigen Wu begonnen!! Die am weitesten berechnete hat 24% - nur macht er halt dort nicht weiter obwohl die Wu angeblich nur 80MB Speicher benötigt.

Hab nun alle 0% WU von LHC gelöscht, aber es kömmt ja nix neues weil Projekt down
 
yupp hatte schon gemerkt das ich mich im Projekt geirrt hatte, da du die WUs schon gelöscht hast ist es ja egal nun...

Welche WUs hatte er den angefangen? Meine Erfahrungen bei LHC VBox Wus sind beschränkt, der Speicherbedarf enorm und sie sind NICHT vergleichbar mit Cosmo (Vbox_MT) also multicore Unterstützung, wärend die LHCb, CMS, Theory alle nur mit 1 Core und mind. 2GB pro WU laufen.
 
Also meine Sixtacks brauchen auch nur um die 80MB, haste unter Speichernutzung schon alles auf 100%? (ist ja nur ein Boinc-Rechner)
 
Speichernutzung ist auf 99% - bei 100% ist TeamViewer nicht mehr zu gebrauchen.

Die angerechneten WU hab ich natürlich nicht gelöscht - bin ja ein zammnemscher (sparsamer) Sachse

das sind die beiden hier :


Mein "Leistungsschwächster" Rechner hingegen knuspert die Sixtrack durch wie trocken Brot

 
Zuletzt bearbeitet:
also die Theory sollte alleine für sich mit andern WUs (Sixtrack braucht <100MB RAM) laufen. Die Atlas ist eine MulticoreVM mit mir unbekannten Speicheranforderungen, aber ich vermute das diese weit über 3,96GB liegen...
 
Die ist eine MulticoreVM mit mir unbekannten Speicheranforderungen, aber ich vermute das diese weit über 3,96GB liegen...

Auch die Atlas mt ist angerechnet, mit 6,11% !! Größe Arbeitspacket 3,32GB , benötigter Arbeitsspeicher 90,34Mb !!

Meine Meinung, es kann ja durchaus sein das die Wu zu groß für den vorhandenen Speicher sind, ABER dann darf
1. die Wu nicht auf dem Rechner landen
2. nicht angerechnet werden
3. schon gar keine anderen Wu blockieren ( durch "warte auf Speicher" wurden Sixtrack "verdrängt" )
 
Ich bin nochmal meine letzte, scheinbar endlos laufende ATLAS WU angegangen.
Da es so aussah als würde sich darin überhaupt nichts mehr tuen (Netzwerkfehler in der WU?) habe ich die VM mal manuell gestartet und beenden (ausschalten) lassen, danach bootete sie mit dem Start im BOINC wieder hoch, sieht nun deutlich anders aus und ist auch deutlich aktiver. Mal gucken ob sie nun durchläuft.

--- Update ---

Sie ist endlich raus! *party*
Da war wohl in der WU irgendwann die Netzwerkverbindung gestorben, wurde in dem toten Zustand abgespeichert und blockierte so die ganze Zeit die Kerne.
Grob geschätzt habe ich dadurch auf 8 Kernen über einen Tag verloren. *zweifel*
 
Am effektivsten rechnet eine Atlas MC mit 4 Kernen, mit jedem weiteren Kern nimmt die Effizienz ab.
Atlas braucht viel Speicher. Laut der Betreiber lässt sich das so ausrechnen.
2,5 GB + 0,8 * Anzahl der Kerne. 3 Kerne = 4,9 GB; 4 Kerne = 5,7 GB; 5 Kerne = 6,5 GB usw.
Auf meinem FX unter Linux laufen 2 WUs mit je 4 Kernen gut, unter Windows kann ich die Kiste nicht mehr bedienen.
 
LHC verteilt wieder Wuzen!!!
 
Habe auf eine PC das Projekt reseten müssen. Dann kam auch da wieder etwas. Aktuell ist aber wieder nur der FX mit WUs versorgt. Der 1700X und der Lappi bekommen schon wieder nichts.

Der Feeder scheint mit größeren Ansturm nicht klar zu kommen *noahnung*
 
Zurück
Oben Unten