10. Pentathlon 2019 - LHC@home (Sprint)

Die ATLAS WUs greifen sich meines Wissens nach schonmal 10 GB RAM ab, da bleibt nicht mehr viel bei 32 GB. ;)

Wenn Theory auf dem Rechner vorhanden sind würde ich die Atlas hinten anstellen. Die dicken Brecher kann man immernoch machen wenn keine Theory mehr da sind.
 
Vorhin war der Server bei Theorie noch leer gelutscht, da wird wohl gerade am Nachschub gearbeitet. :)
 
Mein Rechner hatte sich zuviele Theory geholt, ich hab gerade mal 169 davon wieder zurückgeschickt, bitte hämmert mal alle auf den Update Button!

--- Update ---

Ohne meine laufenden WUs markiert zu haben oder sonstewas hat es mir alle laufenden WUs zerschossen *traurig*
Das waren schon wieder locker 100000 Punkte Fortschritt.

https://lhcathome.cern.ch/lhcathome/result.php?resultid=228463588

Code:
2019-05-16 20:45:21 (3516): Status Report: Job Duration: '64800.000000'
2019-05-16 20:45:21 (3516): Status Report: Elapsed Time: '6000.999928'
2019-05-16 20:45:21 (3516): Status Report: CPU Time: '5704.820000'
2019-05-16 22:24:28 (3516): Status Report: Job Duration: '64800.000000'
2019-05-16 22:24:28 (3516): Status Report: Elapsed Time: '12001.766492'
2019-05-16 22:24:28 (3516): Status Report: CPU Time: '11560.410000'
2019-05-16 22:38:10 (3516): VM is no longer is a running state. It is in 'poweroff'.
2019-05-16 22:38:10 (3516): VM state change detected. (old = 'running', new = 'poweroff')
2019-05-16 22:38:10 (3516): Powering off VM.
2019-05-16 22:38:10 (3516): Deregistering VM. (boinc_9c2968e6ee1a6bb4, slot#4)
2019-05-16 22:38:10 (3516): Removing network bandwidth throttle group from VM.
2019-05-16 22:38:10 (3516): Removing storage controller(s) from VM.
2019-05-16 22:38:10 (3516): Removing VM from VirtualBox.
2019-05-16 22:38:11 (3516): Removing virtual disk drive from VirtualBox.
2019-05-16 22:38:16 (3516): VM Premature Shutdown Detected.

Alle gleichzeitig, eine dreiviertel Minute nachdem der Scheduler request zum Zurücksenden der WUs durch war. Keine Einträge im dmesg log oder sonstwo...
 
Zuletzt bearbeitet:
*rofl*

--- Update ---

Ähm...wie geht das denn? *suspect*
 
Rechner per remote runtergefahren, Grafikkarte eingebaut, alles neu verkabelt, Virtualisierung aktiviert, hochgefahren und er läuft! :D

Ich check nur nicht, warum die Windows-Kiste keine WUs bekommt!
 
Das Problem habe ich bei meinem Konsolero ebenfalls, Bei der Windows 10 Installation heißt es immer das keine WUs da wären und würde sich nur die Sixtrack WUs ziehen, in der Ubuntu VM auf dem gleichen Rechner funktioniert es tadellos und ein anderer Rechner der ebenfalls Windows 10 drauf hat bekommt die VM WUs. Das verstehe wer will. *noahnung*
 
So auch noch schnell alles so umgestellt und noch drei Rechner mehr ins Rennen geschickt,
Aber leider nur per bam.und LCh Seite mal sehn ob das vernünftig klapp, hab ja stündlich Meldung eingestellt
 
Die ATLAS WUs greifen sich meines Wissens nach schonmal 10 GB RAM ab, da bleibt nicht mehr viel bei 32 GB. ;)
Sollte nicht passieren wenn ich die Virtuelle Maschine auf 4,8GB beschränke oder ich verstehe das Prinzip einer VM nicht.

*traurig*
 
Mein Rechner hatte sich zuviele Theory geholt, ich hab gerade mal 169 davon wieder zurückgeschickt, bitte hämmert mal alle auf den Update Button!


Fertig gehämmert und genug bis Sprintende bekommen *great*
 
*rofl*

--- Update ---

Ähm...wie geht das denn? *suspect*

Mir absolut rätselhaft, finde keine Hinweise warum das abgebrochen wurde.
Habe die Gelegenheit gleich mal für nen Neustart genutzt um die permanente Verkleinerung des tmpfs (ua. /tmp) umzusetzen. WU 15 und 16 starten aber immer noch nicht. Bekomme allerdings auch keine Meldungen "Waiting for memory".

--- Update ---

Sehr gut, lasst es krachen!
 
LHC wird nach den Penta wieder schlafen gelegt ;D det is net so meinz
WU 5.358,21h von Gesamt 3.392.247 h
 
Die Kiste hier ist tot. Ich wollte VB aktualisieren, und das Setup startet einfach nicht *admin*
 
Code:
Thu 16 May 2019 23:03:57 CEST | LHC@home | [cpu_sched_debug] enforce: task Theory_3200524_1557996062.996313_0 can't run, too big 2230.00MB > 940.86MB
Thu 16 May 2019 23:03:57 CEST | LHC@home | [cpu_sched_debug] enforce: task Theory_3200519_1557996062.963736_0 can't run, too big 2230.00MB > 940.86MB
Thu 16 May 2019 23:04:01 CEST | WUProp@Home | [mem_usage] data_collect_v4_1557890101_22311_0: WS 13.73MB, smoothed 13.72MB, swap 15.97MB, 0.00 page faults/sec, user CPU 0.140, kernel CPU 0.060
Thu 16 May 2019 23:04:01 CEST | LHC@home | [mem_usage] Theory_3200597_1557996063.744509_0: WS 76.48MB, smoothed 2230.00MB, swap 2006.67MB, 0.00 page faults/sec, user CPU 1.360, kernel CPU 112.970
Thu 16 May 2019 23:04:01 CEST | LHC@home | [mem_usage] Theory_3200308_1557996060.153708_0: WS 581.57MB, smoothed 2230.00MB, swap 2067.18MB, 0.00 page faults/sec, user CPU 2.910, kernel CPU 113.600
Thu 16 May 2019 23:04:01 CEST | LHC@home | [mem_usage] Theory_3200236_1557996058.789394_0: WS 587.23MB, smoothed 2230.00MB, swap 2006.66MB, 0.00 page faults/sec, user CPU 1.560, kernel CPU 112.200
Thu 16 May 2019 23:04:01 CEST | LHC@home | [mem_usage] Theory_3200280_1557996059.203548_0: WS 73.89MB, smoothed 2230.00MB, swap 2004.67MB, 0.00 page faults/sec, user CPU 1.510, kernel CPU 115.430
Thu 16 May 2019 23:04:01 CEST | LHC@home | [mem_usage] Theory_3200291_1557996059.530807_0: WS 591.76MB, smoothed 2230.00MB, swap 2004.67MB, 0.00 page faults/sec, user CPU 1.520, kernel CPU 106.270
Thu 16 May 2019 23:04:01 CEST | LHC@home | [mem_usage] Theory_3200288_1557996059.493804_0: WS 613.57MB, smoothed 2230.00MB, swap 2006.67MB, 0.00 page faults/sec, user CPU 1.780, kernel CPU 113.080
Thu 16 May 2019 23:04:01 CEST | LHC@home | [mem_usage] Theory_3200285_1557996059.458843_0: WS 611.21MB, smoothed 2230.00MB, swap 2004.67MB, 0.00 page faults/sec, user CPU 1.390, kernel CPU 112.930
Thu 16 May 2019 23:04:01 CEST | LHC@home | [mem_usage] Theory_3200713_1557996064.727153_0: WS 76.17MB, smoothed 2230.00MB, swap 2000.53MB, 0.00 page faults/sec, user CPU 1.460, kernel CPU 107.960
Thu 16 May 2019 23:04:01 CEST | LHC@home | [mem_usage] Theory_3200717_1557996064.769417_0: WS 613.72MB, smoothed 2230.00MB, swap 2006.67MB, 0.00 page faults/sec, user CPU 1.460, kernel CPU 110.990
Thu 16 May 2019 23:04:01 CEST | LHC@home | [mem_usage] Theory_3200683_1557996064.505767_0: WS 73.90MB, smoothed 2230.00MB, swap 2067.17MB, 0.00 page faults/sec, user CPU 1.700, kernel CPU 112.900
Thu 16 May 2019 23:04:01 CEST | LHC@home | [mem_usage] Theory_3200721_1557996064.849044_0: WS 587.68MB, smoothed 2230.00MB, swap 2000.67MB, 0.00 page faults/sec, user CPU 1.650, kernel CPU 115.000
Thu 16 May 2019 23:04:01 CEST | LHC@home | [mem_usage] Theory_3200723_1557996064.872157_0: WS 74.24MB, smoothed 2230.00MB, swap 1998.67MB, 0.00 page faults/sec, user CPU 1.610, kernel CPU 113.110
Thu 16 May 2019 23:04:01 CEST | LHC@home | [mem_usage] Theory_3200715_1557996064.747218_0: WS 587.66MB, smoothed 2230.00MB, swap 2000.67MB, 0.00 page faults/sec, user CPU 1.920, kernel CPU 111.500
Thu 16 May 2019 23:04:01 CEST | LHC@home | [mem_usage] Theory_3200439_1557996061.890977_0: WS 609.45MB, smoothed 2230.00MB, swap 2071.17MB, 0.00 page faults/sec, user CPU 1.520, kernel CPU 113.410
Thu 16 May 2019 23:04:01 CEST |  | [mem_usage] BOINC totals: WS 5772.28MB, smoothed 31233.72MB, swap 28262.70MB, 0.00 page faults/sec

BOINC orientiert sich wohl an den der WU mitgegebenen Verbrauchswerten. Tatsächlich verbrauchen die aktuell nur soviel wie der WS Wert angibt, dieser steht wohl für working set. Laut LHC verbrauchen sie aber bis zu 2230MB, was bei 14 WUs 31220MB + 13.72MB WuProp entspricht. Der tatsächliche Verbrauch wird nicht berücksichtigt.
Ich bin mit dem ganzen VB Overhead eh schon bei 100% CPU Last, aber irgendwie juckt es mich da schon an der client_state.xml rumzupfuschen :-D
 
Irgendwie bin ich zu doof für dieses Projekt, scheints... :P
 
Sollte nicht passieren wenn ich die Virtuelle Maschine auf 4,8GB beschränke oder ich verstehe das Prinzip einer VM nicht.

*traurig*

Ich ändere da garnichts, die ATLAS VBox WUs (8 Kerne) reservieren sich die 10 GB und wenn sie nicht verfügbar sind starten sie wegen Speichermangel nicht.

Edit: ich habe gerade nochmal bei meinem Schleppi nachgesehen das der WU nur 3 Kerne gönnt, die zwackt von sich aus nur noch 5,7 GB RAM ab.
 
Auf die Gefahr hin zu nerven, aber ich möchte noch mal darauf hinweisen das wir nur mit VM WUs (idealerweise Theory) die Chance auf einen Blumentopf haben.
WCG ist save, NFS scheint den Berechnungen zufolge in trockenen Tüchern.
Hier bei LHC haben wir die Chance noch einmal glänzen zu können, müssen dazu die Eigenheiten des Projekts zu unseren Gunsten nutzen. Dh. nicht das einfachste oder irgendwas zu rechnen.

Zum Vergleich:
https://lhcathome.cern.ch/lhcathome...389189&offset=0&show_names=0&state=4&appid=13
Mein Rechner (R7 1700) benötigt im Durchschnitt 54370s für eine Theory Einheit, bekommt dafür 10260 Credit. Ergibt bei 16 Threads 260000 Credit.

https://lhcathome.cern.ch/lhcathome/results.php?hostid=4810825&offset=0&show_names=0&state=4&appid=1
ebenfalls ein R7 1700, benötigt 4300 Sekunden im Durchschnitt pro Sixtrack, bekommt dafür 28,14 Credit. Ergibt 9045 Credits pro Tag bei 16 Threads.

Das ist ein Faktor von 1:28. Ein ausschließlich Theory rechnender Rechner erzeugt genausoviele Credit wie 28 gleichstarke Rechner mit Sixtrack.

Mit Sixtrack kommen wir nicht weit, können froh sein wenn es bei Bronze bleibt. Da können wir nochsoviele Kerne drauf ansetzen.
Bei Rechenkraft sind auch nur eine Hand voll Leute produktiv, trotzdem sind sie auf Platz 2. Weil VirtualBox eingesetzt wird um VM WUs zu berechnen.
Lasst es uns ihnen gleichtun!


Wer schon Sixrack rechnet sollte sich eine parallele BOINC Instanz anlegen und starten, diese einem Profil zuweisen das ausschließlich Theory (nicht "Theory Native") erlaubt.
Siehe Bild:

Anhang anzeigen 38448

Nun regelmäßig nach Arbeit fragen, wenn nichts kommt eine Schleife bauen die regelmäßig folgenden Befehl absetzt:
Code:
boinccmd --project https://lhcathome.cern.ch/lhcathome/ update
Das sollte auch unter Windows gehen.

Sobald Arbeit (Theory) kommt, Sixtrack auf dem Primärboinc anhalten, ausschließlich Theory rechnen.
Wem das mit den parallelen BOINC Instanzen zu umständlich ist, Profil bei LHC anpassen (Sixtrack, Atlas, CMS raus), Bunkereinstellungen hochsetzen, regelmäßig nach Arbeit fragen. Sobald Theory kommen, Sixtrack pausieren.

Nicht vergessen mehr RAM zu erlauben über den BOINC-Manager, damit möglichst viele WUs parallel laufen können.

Die Einstellung "Max # of CPUs for this project 1" im Profil könnte das gleiche bewirken wie eine app_info.xml, ich habs aber nicht ausprobiert. Werden trotzdem WUs gezogen die 2,4,8,etc Kerne zeigen, diese über die hier schon mehrfach gepostet app_info.xml auf einen Kern beschränken, BOINC Konfigurationsdateien einlesen bzw. Neustarten.


JA mir ist bewusst das Theory nicht immer die massiven Punkte ausspuckt. Aber selbst wenn nicht, dann ist die Ausschüttung immernoch besser als bei Sixtrack. Wer nicht wagt der nicht gewinnt. Wenn das auch nur bei jedem dritten funktioniert und sich dort der Ausstoß um den Faktor 28 erhöht, dann haben wir schon gewonnen.
1/3 unserer Punkte heute bisher wurden von einem R7 erzeugt. Lasst weitere Maschinen folgen!

Danke für diese Einblicke.
Ich mach grade noch die angefangenen Sixtrack zu Ende, dann kommt Theory dran.
3 hat er bisher (6CPUs steht da)
Prima ist auch die Downloadrate. 158 kbps bei 100mb+ pro WU.
 
Hmm, der Download war bei mir OK...
Code:
Thu 16 May 2019 23:16:15 CEST | WUProp@Home | [mem_usage] data_collect_v4_1557890101_22311_0: WS 13.70MB, smoothed 13.65MB, swap 15.91MB, 0.00 page faults/sec, user CPU 0.150, kernel CPU 0.020
Thu 16 May 2019 23:16:15 CEST | LHC@home | [mem_usage] Theory_3200597_1557996063.744509_0: WS 88.22MB, smoothed 2230.00MB, swap 2230.12MB, 0.00 page faults/sec, user CPU 1.900, kernel CPU 27.940
Thu 16 May 2019 23:16:15 CEST | LHC@home | [mem_usage] Theory_3200308_1557996060.153708_0: WS 73.74MB, smoothed 2230.00MB, swap 1904.54MB, 0.00 page faults/sec, user CPU 1.030, kernel CPU 34.440
Thu 16 May 2019 23:16:15 CEST | LHC@home | [mem_usage] Theory_3200236_1557996058.789394_0: WS 74.00MB, smoothed 2230.00MB, swap 2030.34MB, 0.00 page faults/sec, user CPU 1.360, kernel CPU 32.730
Thu 16 May 2019 23:16:15 CEST | LHC@home | [mem_usage] Theory_3200280_1557996059.203548_0: WS 87.54MB, smoothed 2230.00MB, swap 2201.61MB, 0.00 page faults/sec, user CPU 1.090, kernel CPU 30.960
Thu 16 May 2019 23:16:15 CEST | LHC@home | [mem_usage] Theory_3200291_1557996059.530807_0: WS 75.58MB, smoothed 2230.00MB, swap 1932.54MB, 0.00 page faults/sec, user CPU 1.250, kernel CPU 29.070
Thu 16 May 2019 23:16:15 CEST | LHC@home | [mem_usage] Theory_3200288_1557996059.493804_0: WS 75.46MB, smoothed 2230.00MB, swap 1974.40MB, 0.00 page faults/sec, user CPU 0.970, kernel CPU 35.010
Thu 16 May 2019 23:16:15 CEST | LHC@home | [mem_usage] Theory_3200285_1557996059.458843_0: WS 73.70MB, smoothed 2230.00MB, swap 1974.55MB, 0.00 page faults/sec, user CPU 1.150, kernel CPU 30.430
Thu 16 May 2019 23:16:15 CEST | LHC@home | [mem_usage] Theory_3200713_1557996064.727153_0: WS 90.64MB, smoothed 2230.00MB, swap 2135.61MB, 0.00 page faults/sec, user CPU 1.040, kernel CPU 31.180
Thu 16 May 2019 23:16:15 CEST | LHC@home | [mem_usage] Theory_3200717_1557996064.769417_0: WS 73.79MB, smoothed 2230.00MB, swap 1952.54MB, 0.00 page faults/sec, user CPU 1.230, kernel CPU 29.180
Thu 16 May 2019 23:16:15 CEST | LHC@home | [mem_usage] Theory_3200683_1557996064.505767_0: WS 73.72MB, smoothed 2230.00MB, swap 1940.54MB, 0.00 page faults/sec, user CPU 1.370, kernel CPU 29.130
Thu 16 May 2019 23:16:15 CEST | LHC@home | [mem_usage] Theory_3200721_1557996064.849044_0: WS 73.86MB, smoothed 2230.00MB, swap 1968.55MB, 0.00 page faults/sec, user CPU 1.850, kernel CPU 28.970
Thu 16 May 2019 23:16:15 CEST | LHC@home | [mem_usage] Theory_3200723_1557996064.872157_0: WS 73.56MB, smoothed 2230.00MB, swap 2025.18MB, 0.00 page faults/sec, user CPU 1.200, kernel CPU 29.590
Thu 16 May 2019 23:16:15 CEST | LHC@home | [mem_usage] Theory_3200715_1557996064.747218_0: WS 90.06MB, smoothed 2230.00MB, swap 2167.61MB, 0.00 page faults/sec, user CPU 2.300, kernel CPU 27.790
Thu 16 May 2019 23:16:15 CEST | LHC@home | [mem_usage]  (not running)Theory_3200439_1557996061.890977_0: WS 87.62MB, smoothed 2230.00MB, swap 2125.61MB, 0.00 page faults/sec, user CPU 1.020, kernel CPU 24.500
[B]Thu 16 May 2019 23:16:15 CEST | LHC@home | [mem_usage] Theory_3200524_1557996062.996313_0: WS 73.44MB, smoothed 322.65MB, swap 1836.54MB, 0.00 page faults/sec, user CPU 0.710, kernel CPU 16.940[/B]
Thu 16 May 2019 23:16:15 CEST | LHC@home | [mem_usage] Theory_3200519_1557996062.963736_0: WS 89.88MB, smoothed 2230.00MB, swap 2059.61MB, 0.00 page faults/sec, user CPU 0.680, kernel CPU 18.130
Thu 16 May 2019 23:16:15 CEST |  | [mem_usage] BOINC totals: WS 1288.53MB, smoothed 33786.30MB, swap 32475.82MB, 0.00 page faults/sec

Habe mal in der client_state.xml bei zwei WUs den Speicherverbrauch heruntergesetzt, damit eine WU mehr gestartet bekommen, hurra! Nur noch 100 anzupassen...
 
Auch wenn ich mich wiederhole, dass ist für den Sprint das mit Abstand schlechteste Projekt das man sich raussuchen konnte. extrem unterschiedliche WU Verteilung bei den Unterprojekten, extremer RAM Hunger der Credit starken Unterprojekte, so gut wie keine Vorbunker- oder Test Moglichkeiten wegen fehlender WU Versorgung der kritischen Unterprojekte und wir basteln hier seit einem Tag von einem 3 Tage Race um den Kram halbwegs zum laufen zu bekommen. :]
 
Hmm, wann müsste man bei den Theory-WUs einen Fortschritt sehen?
Estimatet gut 10 Stunden, vergangen bisher --:-- und Fortschritt 00:000%
Ist aber eine für 6CPUs, das hab ich im Projekt jetzt nochmal auf 1 reduziert.
Die Meldungen scheinen frei von Fehlern zu sein.
Laut Taskmanager habe ich eine CPU-Last von ca. 20%.

--- Update ---

Hmm, wann müsste man bei den Theory-WUs einen Fortschritt sehen?
Estimatet gut 10 Stunden, vergangen bisher --:-- und Fortschritt 00:000%
Ist aber eine für 6CPUs, das hab ich im Projekt jetzt nochmal auf 1 reduziert.
Die Meldungen scheinen frei von Fehlern zu sein.
Laut Taskmanager habe ich eine CPU-Last von ca. 20%.

Hmm, nachdem ich einmal auf 100% Prozessornutzung gestellt habe und er zusätzlich zwei 95% fertige Sixtracks wieder weiterberechnet hat, läuft auch der Fortschritt bei der Theory los. Sehr seltsames Verhalten.
 
Im Nachhinein bringen Änderungen in den Projekteinstellungen nichts mehr, die gelten nur jeweils für neu geladene WUs.
Die Theory laufen eigentlich sofort los, sowohl was Zeit als auch Fortschritt betrifft.

@Sompe

hätte besser laufen können, betrifft ja aber alle Teams gleichermaßen. Machen wir das beste daraus!
 
Nun ja, es ist ja nicht so dass ich mir bisher nicht zu helfen gewusst hätte aber bisher verhält sich das Projekt wie eine mittlere Katastrophe, siehe mein einer Rechner den der Server bei der Windows Installation nur mit Sixtrack beliefern will oder die von hause aus nicht lauffähigen nativen Linux WUs. *admin*
 
kann man der Restzeitanzeige trauen ? Oder anders gefragt, kann die Laufzeit über 20 Stunden dauern ?
 
18h laufen die Theory bei mir maximal, viele sind vorher fertig.
Die Anzeige taugt aber nicht.

Die nativen WUs sollten auf jeden Fall mit doppelten opt-in mit dicken fetten Warnzeichen und Link zur Einrichtung sein.
 
Zurück
Oben Unten