Neue WUs bei LHC@Home!

Juhu, die Atlas und Theory Nativen laufen diesmal durch! Ja also mit der Commando Zeile bin ich ein wenig bewandert, jedoch nicht beim Kompilieren, da weiß ich immer noch nicht was ich da tue. In Linux lerne ich in mini Schritte immer mehr hinzu, habe aber immer noch genug Fragen auf der Stirn stehen, wie ich selber etwas kompilieren, installieren kann, ohne dabei auf die Linux Mint/ubuntu Pakete zurück greifen zu müssen.

Warum laufen die CMS WUs nicht, weiß das einer von euch?

--- Update ---

VIRTUALBOX für CMS separat installieren führt nur dazu das diese eher abgebrochen werden, habe diese nun auf der Webseite ausgeklammert.
 
Waren die CMS nicht mal fehlerhaft und sollten deshalb nicht mehr berechnet werden? Die Meldung war aber schon einige Monate her. *kopfkratz

Das Installationsscript hatte ich damals nicht genutzt (blicke da eh nicht richtig durch) sondern die Punkte einzeln kopiert und installiert.
 
Ja die CMS Meldung das die fehlerhaft durchlaufen sollen etc lass ich bei denen auch, von daher fragte ich mich auch ob sich das darauf noch bezieht. Nun ja dafür laufen ja soweit ich das sehen kann, alle anderen Erfolgreich, die 12 Stunden Theory VirtualBox WUs haben sich selber abgebrochen, umso besser denke ich.

Zurzeit läuft alles an Atlas und Theory nativ

Aber da vorher alle anderen VirtualBox WUs durchgelaufen sind, müssen die CMS ja fehlerhaft sein.

Auch ohne VirtualBox und nativ Rattert die HDD immer noch ganz gut durch.

Jedoch gerade Mal 6 GB RAM belegt, dass ist in der Tat deutlich sparsamer als die virtuellen, da war ja 24 GB RAM belegt.

--- Update ---

Auf PC Nr. 2 läuft nun auch Atlas und Theory und musste diesmal kein VirtualBox installieren, es reicht vorher völlig aus, die obere Anleitung zu nutzen und danach LHC an machen, dann klappt es super .

Ich muss nur gucken, die Platte ist langsamer und dort Passen nur 100 GB insgesamt drauf.

--- Update ---

Lohnt es sich überhaupt 32 WUs gleichzeitig laufen zu lassen? Ich habe eher den Eindruck, als ob eher die Festplatte limiert, dass zeigen auch die Zeiten auf der Webseite. Bei weniger WUs steigt dagegen die Rechenzeit nach oben.

--- Update ---

Wenn ich Mal Stichproben artig gucke,so bricht bei jemand anders , wo die CMS normalerweise durch gehen, zurzeit auch ab.

--- Update ---

Was sind denn eure Erfahrungen mit den Theory nativ WUs, welche Laufzeiten waren für euch normal und ab welcher Laufzeit bricht ihr ab?
 
Zuletzt bearbeitet:
Die Theory Laufzeiten schwankten bei mir immer stark aber nach 10 Stunden waren sie idR. tot und "rannten" ins Timeout.
Spätestens nach 7 Stunden Laufzeit sollte man über die Projektseite aber mal in die History der WU schauen. Ist sie da schon bei anderen ins Timeout gerannt kann man sie in die Tonne kloppen.
 
Ich hab ein wenig in deren Forum gelesen und bei den Theory gibt es verschiedene Typen, sobald sherpa läuft, ist besonderes Augenmerk gefragt, oder wenn man auf die keine Lust hat, einfach abbrechen. Das sind die, die in der Regel so lange laufen und dann ab 100 Std. automatisch abgebrochen werden, obwohl die noch gar nicht fertig sind, aber an und für sich noch Rechenzeit brauchen. Man kann allerdings paar Dateien editieren, damit das 100 Std. Limit aufgehoben wird.

Alle anderen Theory Typen, z.B. pythia laufen normal, bzw. kürzer. ich hatte gerade noch andere Typen gesehen.

Code:
integration time:  ( 9h 33m 43s elapsed / 154d 12h 55m 3s left ) [20:26:51]   
1.7926e+25 pb +- ( 3.53434e+24 pb = 19.7163 % ) 489960000 ( 489962598 -> 99.9 % )
integration time:  ( 9h 33m 44s elapsed / 154d 13h 5m 16s left ) [20:26:53]   
1.79325e+25 pb +- ( 3.53421e+24 pb = 19.7084 % ) 489980000 ( 489982598 -> 99.9 % )
integration time:  ( 9h 33m 46s elapsed / 154d 10h 15m 21s left ) [20:26:54]   
1.79318e+25 pb +- ( 3.53406e+24 pb = 19.7084 % ) 490000000 ( 490002598 -> 99.9 % )
integration time:  ( 9h 33m 48s elapsed / 154d 10h 25m 52s left ) [20:26:56]   
1.7931e+25 pb +- ( 3.53392e+24 pb = 19.7084 % ) 490020000 ( 490022598 -> 99.9 % )
integration time:  ( 9h 33m 49s elapsed / 154d 10h 36m 51s left ) [20:26:58]   
1.79303e+25 pb +- ( 3.53377e+24 pb = 19.7084 % ) 490040000 ( 490042598 -> 99.9 % )
integration time:  ( 9h 33m 51s elapsed / 154d 10h 46m 9s left ) [20:26:59]   
1.79296e+25 pb +- ( 3.53363e+24 pb = 19.7084 % ) 490060000 ( 490062598 -> 99.9 % )
integration time:  ( 9h 33m 52s elapsed / 154d 10h 55m 31s left ) [20:27:01]   
1.79288e+25 pb +- ( 3.53348e+24 pb = 19.7084 % ) 490080000 ( 490082598 -> 99.9 % )
integration time:  ( 9h 33m 54s elapsed / 154d 11h 6m 29s left ) [20:27:03]   
Phase_Space_Integrator::AddPoint(): value = -nan. Skip.
1.79281e+25 pb +- ( 3.53334e+24 pb = 19.7084 % ) 490100000 ( 490102598 -> 99.9 % )
integration time:  ( 9h 33m 55s elapsed / 154d 11h 15m 52s left ) [20:27:04]   
1.79274e+25 pb +- ( 3.5332e+24 pb = 19.7084 % ) 490120000 ( 490122598 -> 99.9 % )
integration time:  ( 9h 33m 57s elapsed / 154d 11h 26m 54s left ) [20:27:06]   
1.79266e+25 pb +- ( 3.53305e+24 pb = 19.7084 % ) 490140000 ( 490142598 -> 99.9 % )
integration time:  ( 9h 33m 59s elapsed / 154d 11h 37m 44s left ) [20:27:08]   
1.79259e+25 pb +- ( 3.53291e+24 pb = 19.7084 % ) 490160000 ( 490162598 -> 99.9 % )
integration time:  ( 9h 34m elapsed / 154d 11h 48m 21s left ) [20:27:10]   
1.79252e+25 pb +- ( 3.53276e+24 pb = 19.7084 % ) 490180000 ( 490182598 -> 99.9 % )
integration time:  ( 9h 34m 2s elapsed / 154d 11h 59m 19s left ) [20:27:12]

Wer diese besonderen Theory WUs im Auge behalten möchte, im Arbeitsverzeichnis von BOINC befindet sich eine Datei runRivet.log für die Native Ausführung, dort steht drin, wie der Fortschritt tatsächlich aussieht. Meine braucht noch viel länger als 100 Std. und ist noch lange nicht fertig.
 
Zuletzt bearbeitet:
Mit anderen Worten, sinnlose WUs. ;)
Ich für meinen Teil habe dieses Unterprojekt deshalb abgewählt.
 
Ja wahrscheinlich auch nur, da das Limit zu kurzfristig ist, nun rechnet ein Computer aktuell nur sherpa, nach dem ich in die Log geschaut habe, werden die alle über das Limit kommen, die brauchen alle mehrere Wochen und so lange dürfen die ja nicht. Selbst wenn ich die Datei zum 100 Stunden aufhebe, Länder wie 1 Woche dürfen die ja generell nicht. Aber wenn in der Log steht das die 150 Tage benötigen könnten, kommen die ja auch nach 1 Woche ans Limit und somit rennen die ja leider ins Time Out und sind dann tatsächlich nutzlos. Aber das wissen die bei LHC und ändern nichts daran .... Die kommen dann mit ihrer Statistik und beleben, dass auch diese WUs durchaus durchlaufen....

Die müssten wie bei Rosetta sein, nach 24 Stunden rechnet jemand anders daran weiter. Anstatt das die ins Error gehen und Punkte verloren gehen.
 
Zuletzt bearbeitet:
Dieses Linux treibt mich mal wieder in die Raserei:
Nachdem ich ja gerade Zeit habe, versuche ich die LHC native WUs auf einer Mint-Büchse (aktuelles Patch-Level) ans Laufen zu bekommen (ich dachte, das hätte da sogar schon mal funktioniert) - aber ich reite mich immer weiter in den Morast:
Das Skript funktioniert nicht, also habe ich mich an dem offiziellen LHC-guide versucht - und da stolper' ich von einer Abhängigkeit in die nächste beim Versuch, den Schmodder zu kompilieren (hab' schon "cmake uuid-dev libfuse-dev python-dev libcap-dev attr autofs git ninja-build gcc gdb clang qt5-default python-setuptools" installiert) und aktuell meint er, dass die "zlib.h" fehlt, obwohl:
cmake --find-package -DCOMPILER_ID=GNU -DLANGUAGE=CXX -DMODE=EXIST -DNAME=ZLIB
ZLIB found.

???

Kann mir jemand durch dieses fiese Level im längsten Textadventure der Welt helfen??
 
also ich habe diesen SH Skript gar nicht genutzt, sondern ich habe einfach kopieren und einfügen genommen, für jede Zeile wie folgt:
wget https://ecsft.cern.ch/dist/cvmfs/cvmfs -release / cvmfs-release-latest_all.deb
sudo dpkg -i cvmfs-release-latest_all.deb
rm -f cvmfs-release-latest_all.deb
sudo apt-get update
sudo apt get-cvmfs cvmfs-config-default install
sudo cvmfs_config Setup
sudo wget https://lhcathome.cern.ch/lhcathome/download/default.local -O /etc/cvmfs/default.local
sudo cvmfs_config
sudo sed -i '$ a \ kernel.unprivileged_userns_clone = 1' / etc / sysct neu laden .conf
sudo sysctl -p
sudo wget http://lhcathome.cern.ch/lhcathome/download/create-boinc-cgroup -O / sbin / create-boinc-cgroup
sudo wget http://lhcathome.cern.ch/lhcathome/download/boinc-client .service -O /etc/systemd/system/boinc-client.service
sudo systemctl daemon-
reload sudo systemctl boinc-client neu starten

Danach mache ich noch den Test:
cvmfs_config probe

Der dann im optimalen Fall so aussehen sollte:
Probing /cvmfs/atlas.cern.ch... OK
Probing /cvmfs/atlas-condb.cern.ch... OK
Probing /cvmfs/grid.cern.ch... OK
Probing /cvmfs/cernvm-prod.cern.ch... OK
Probing /cvmfs/sft.cern.ch... OK
Probing /cvmfs/alice.cern.ch... OK

Ich habe das o.g. vorgehen auf 2 aktuelle Linux Mint Büchsen angewandt und läuft super.

Mit dem Kompilieren und den Abhängigkeiten komme ich leider auch nicht weiter, ich suche möglichst auch immer einen wegen, wie oben, der dann geht.
 
Geht bei mir leider schon bei der allerersten Zeile wieder in die Hose:
wget: Ungültiger »--execute«-Befehl »lease«
(Meint nicht nur Mint, sondern auch Manjaro)

Wobei sich mir nicht erschließet, woher er "lease" als Befehl nimmt? ???
 
Einmal vorweg 'sudo su', dann braucht man nicht jedes Mal 'sudo' zu Beginn.

Mint basiert auf Ubuntu, aber irgendwie müssen die Komandozeilen anders aussehen:

Code:
Zeile 1: wget https://ecsft.cern.ch/dist/cvmfs/cvmfs-release/cvmfs-release-latest_all.deb
Zeile 2: dpkg -i cvmfs-release-latest_all.deb
Zeile 3: rm -f cvmfs-release-latest_all.deb
Zeile 4: apt-get update
Zeile 5: apt install cvmfs-config-default
Zeile 6: [COLOR="#FF0000"]cvmfs_config setup[/COLOR] Wofür steht das 'setup'?
Zeile 7: wget https://lhcathome.cern.ch/lhcathome/download/default.local -O /etc/cvmfs/default.local
Zeile 8: [COLOR="#FF0000"]cvmfs_config reload[/COLOR] Welche Datei soll neu geladen werden?
Zeile 9: sed -i '$ a \ kernel.unprivileged_userns_clone = 1' /etc/sysctl.conf
Zeile 10: sudo sysctl -p
Zeile 11: wget http://lhcathome.cern.ch/lhcathome/download/create-boinc-cgroup -O /sbin/create-boinc-cgroup
Zeile 12: wget http://lhcathome.cern.ch/lhcathome/download/boinc-client.service -O /etc/systemd/system/boinc-client.service
Zeile 13: systemctl daemon-reload
Zeile 14: /etc/init.d/boinc-client restart

(Sorry, aber ich baue nebenbei den neuen Cluster-Rechner P3D-Raspo zusammen, und esse Abendbrot)
 
Zuletzt bearbeitet:
Ich habe gerade rund 16 Theory WUs gekillt, die 1-2 Tage, manche auch edliche Stunden gelaufen sind, dabei ging ich nach den Log Dateien und wenn mir die zu unschüssig waren, killte ich die. Denn PC 1 kam mit der Menge an Langläufer WUs nicht mehr so richtig von der stelle und blockierte die ganze CPU damit und Festplatte, die einen Lärm ohne ende gemacht hatte.

Wobei ich sagen muss, dass 245 WUs davon ordentlich durchgelaufen sind, davon gabs sogar 24 Std. Langläufer, die tatsächlich auch beendet wurden, deswegen habe ich so lange bei den anderen Langläufern gezögert, kille ich die, oder lasse ich die noch laufen, vor allem in Bezug auf das Forum von denen wo auch über die Theory WUs geschrieben wurde.

Nun ja, es gibt ja wieder neue WUs die dann hoffendlich nicht direkt die ganze CPU blockiert. Wenn es von den 32, 1-2 CPU Kerne sind, kräht bei mir allerdings kein Hahn nach, nur bitte nicht die ganze CPU :D

Auf PC2 Scheinen es zurzeit 2 Theory Langläufer zu geben, nur da komme ich nicht am Computer, so das ich die nach 4 Tagen automatisch killen lasse, alle anderen Theory WUs sind erstaunlicherweise super durchgelaufen. Auf PC2 sind es zurzeit 414 Gültige.

Ich lasse eine seit 2 Tagen laufen, wenn ich mir den Inhalt der Log Datei anschaue, müsste die ja bald fertig sein:
dumping histograms...
Event 73100 ( 1h 10m 13s elapsed / 25m 50s left ) -> ETA: Sun Apr 12 17:20
73100 events processed
Event 73200 ( 1h 10m 16s elapsed / 25m 43s left ) -> ETA: Sun Apr 12 17:20
73200 events processed
Error in Splitting_Tools::ConstructKinematics(kt = -nan, z = 0.9674, y = 0.01344).
Error in Splitting_Tools::ConstructKinematics(kt = -nan, z = 0.5623, y = 0.3078).
Event 73300 ( 1h 10m 22s elapsed / 25m 38s left ) -> ETA: Sun Apr 12 17:20
73300 events processed
Event 73400 ( 1h 10m 26s elapsed / 25m 31s left ) -> ETA: Sun Apr 12 17:20
73400 events processed
Event 73500 ( 1h 10m 30s elapsed / 25m 25s left ) -> ETA: Sun Apr 12 17:20
73500 events processed
Event 73600 ( 1h 10m 34s elapsed / 25m 18s left ) -> ETA: Sun Apr 12 17:20
73600 events processed
Event 73700 ( 1h 10m 38s elapsed / 25m 12s left ) -> ETA: Sun Apr 12 17:20
73700 events processed
Error in Splitting_Tools::ConstructKinematics(kt = -nan, z = 0.2535, y = 0.506).
Error in Splitting_Tools::ConstructKinematics(kt = -nan, z = 0.3639, y = 0.4602).
Error in Splitting_Tools::ConstructKinematics(kt = -nan, z = 0.9753, y = 0.01348).
Event 73800 ( 1h 10m 42s elapsed / 25m 6s left ) -> ETA: Sun Apr 12 17:20
73800 events processed
Event 73900 ( 1h 10m 45s elapsed / 24m 59s left ) -> ETA: Sun Apr 12 17:20
73900 events processed
Event 74000 ( 1h 10m 49s elapsed / 24m 53s left ) -> ETA: Sun Apr 12 17:20
XS = 4.153e+05 pb +- ( 1518 pb = 0.36 % )
74000 events processed
dumping histograms...
Event 74100 ( 1h 10m 53s elapsed / 24m 46s left ) -> ETA: Sun Apr 12 17:20
74100 events processed
 
Zuletzt bearbeitet:
@thorsam:
Vielen Dank schonmal - dann warte ich noch etwas, jetzt hänge ich nämlich genau an Zeile 6:
sudo: cvmfs_config: Befehl nicht gefunden
 
@thorsam:
Vielen Dank schonmal - dann warte ich noch etwas, jetzt hänge ich nämlich genau an Zeile 6:
sudo: cvmfs_config: Befehl nicht gefunden

Ich würde mal schauen, ob es eine ähnliche Datei gibt in dem Verzeichnis, vielleicht mit - statt _
Oder die Datei ist nicht als ausführbar markiert.
 
Wenn ich im LHC-Forum richtig rumstochere, hat es irgendetwas mit der 'default.local' zu tun.

For those who are already running Native Atlas tasks, please update the default.local file with command above and then reload the configuration with:

sudo cvmfs_config reload

Analog dazu der Befehl aus Zeile 6.
 
Ich komme immer nur bis Zeile 5 - danach kennt er cvmfs_config nicht (Befehl nicht gefunden)...

Beim nochmaligen Ausführen ist mir bei Schritt 2 aber folgende Meldung aufgefallen:
Warning: this distribution is not supported. Using Ubuntu 18.04 packages as fallback.

Vielleicht klappt das ja nicht - ist Mint (Tessa) zu neu? ???

Mit Manjaro kann ich das parallel ja wieder nicht testen, weil unterschiedliche Befehle (suche da noch)... *chatt*
(Da hatte ich Native Atlas vorher definitiv nicht am Laufen - diese Installation ist nämlich noch keine 2 Wochen alt)

Edit:
Unsere Freunde der Alliance Francophone haben einen Guide geschrieben, der für mich (für Mint & Manjaro!) zu funktionieren scheint:
https://forum.boinc-af.org/index.php?topic=8046.0
(französisch ;))

Nur konnte ich beide noch nicht testen: Mint meint, dass knapp 6 GB freier Plattenplatz noch mind. 4 GB zuwenig sind (*chatt*) und bei Manjaro muss ich noch warten bis die ARPs durch sind, weil die so ein miserables Checkpointing haben... :]
 
Zuletzt bearbeitet:
Meine CPU Cruncher laufen mit Ubuntu und da läuft die Installation der einzeln kopierten Schritte. *noahnung*
 
Ich komme immer nur bis Zeile 5 - danach kennt er cvmfs_config nicht (Befehl nicht gefunden)...
Es ist ja auch kein Befehl, da wird das Programm aufgerufen. Darum wäre mein erster Blick, ob die Datei vorhanden ist und wenn ja, wo sie liegt.
 
Es ist ja auch kein Befehl, da wird das Programm aufgerufen. Darum wäre mein erster Blick, ob die Datei vorhanden ist und wenn ja, wo sie liegt.

"Indirekt" war's das wohl: der Install-Befehl scheint nicht wirklich geklappt zu haben - mit der von mir im vorigen Post verlinkten Anleitung (die ist auch noch kürzer... ???) scheint es nun aber zu funktionieren - zumindest bin ich mal ein ganzes Stück weiter ;D
 
Mit der erwähnten Anleitung läuft es unter Mint jetzt - zumindest die erste Theory WU wurde erfolgreich berechnet!
Auf eine ATLAS-WU muss ich noch warten...
(Ebenso wie auf den Test unter Manjaro)
 
Also ich hatte nun die ganze Zeit wunderbare Theory WUs gehabt, wo ich wirklich nicht meckern konnte und habe die dadurch natürlich sehr gerne genommen und durchrechnen lassen, aber jetzt die letzten scheinen alle von anderen davor abgebrochen worden zu sein und die habe ich nun alle bekommen und klappen dann bei mir natürlich auch nicht und rechnet sich dumm und dämlich. Aber mal gucken, ist jetzt erstmal 1 Std. vergangen. Wenn das so weiter geht, werde ich um diese auch einen Bogen machen.

--- Update ---

Also ich gucke nun, dass der Arbeitspuffer so gefüllt ist, dass er immer 2 Atlas gleichzeitig berechnet, dass wären 24 belegte CPU Kerne und den Rest kann er dann ruhig mit Theory WUs nutzen und zwar so lange bis das Automatische 4 Tage Limit kommt. Aber die meisten hat er nun wieder rechtzeitig fertig bekommen. Auf PC2, wo ich nicht eingreifen möchte, werden allerdings schon sehr bald 4 Tage laufen und dann kommen neue.

Ich finde durch die ständigen Atlas werden genug Punkte abgeworfen, selbst wenn die Theory alle laufen, ich finde die machen dagegen kaum Punkte. Die fallen kaum ins Gewicht.
 
Ich bekomm' an der einen Maschine keine Atlas - und im Log keinen Hinweis, warum dem so ist.
Theory läuft...
 
Also ich hatte gestern Abend und heute Nachmittag auf PC1 jede Menge Theory WUs abgebrochen, die ich jetzt alle habe und die auf PC2 sind wiederum überwiegend gut. Aber man muss tatsächlich zu jeder Zeit ein Auge drauf werfen. Also eigentlich sind für mich die Theory Alpha, bzw. Beta Test WUs, wo jemand ständig nachgucken muss ob die laufen, oder in den Apfel beist und sagt okay, maximal 4 Tage, danach ist ende, dann zur nächsten. Wenn es dann nur 1-2 WUs sind die dann mal nicht laufen ist das Verfahren anschließend noch zu verschmerzen, aber nicht wenn danach gleich 32 WUs kommen. Ich habe deutlich über 40 WUs abgebrochen, damit ich danach wieder normale erhalte.

Die Atlas laufen dagegen immer.

Aber okay, ich lasse dennoch die Theory WUs laufen, ich habe ja schon hunderte erfolgreich durchführen lassen können. Sprich 855 WUs auf beiden Computern und davon habe ich 55 abgebrochen. Also vom Verhätlnis her gehts vielleicht noch....
 
Bei mir waren's 4 Theories - aber nur mit 2 Threads auf einem Celeron G1610 ;)
Die liefen recht kurz, aber erfolgreich durch...
ATLAS kriegt er nicht - mal schauen, ob sich das morgen beim 9800E ändert (der muss bis dahin noch ARP fertigrechnen)...
 
Ich glaube die Atlas bekommt man für Nativ nur für mindestens 12 Kerne und die VirtualBox Atlas für mindestens 8 Kerne. Also bei mir beansprucht er 12 Kerne, da der 3950 32 Kerne besitzt, eröffnet er 2 Atlas WUs, jedoch keine 3x, somit lastet LHC den AMD nur mit 2x 12 = 24 Kerne aus, die restlichen rechnen dann irgentetwas anderes. Aber es ist schon so das er die 12 Kerne beansprucht und die anderen WUs solange pausiert und dafür abzweigen muss.

Ja die können recht kurz sein, allerdings auch super lang bis 10 Stunden. Im LHC Forum berichtet einer sogar mit 6 Tage als Erfolgreiche WU, aber dafür muss man dann ein Laufzeitenlimit aushebeln, damit die WUs überhaupt über 4 Tage laufen dürfen.... ich habe festgestellt, dass ich für die Log Datei zur Kontrolle viel zu wenig Erfahrung habe und die 4 Tage Regel schon ganz gut finde. Es gibt im LHC Forum auch einen Link zu einer riesen großen Liste zum nachschauen, welche WUs erfolg versprechen und welche man eher abbrechen soll... denn die schlechten WUs werden nicht herausgefiltert, die dürfen wir schön brach herunterladen und berechnen lassen. :D Naja okay.

--- Update ---

Ach und bei den Theory WUs, wenn diese Nativ laufen, darf man BOINC durch Neustarts oder Herunterfahren des Comuters nicht unterbrechen, im Speicher belassen während BOINCläuft geht schon. Sonst rechnet er wieder von vorne. Bei VirtualBox darf man unterbrechen.
 
Zurück
Oben Unten