LHCathome-dev

[pilotpirx]

Mache mal für das og. Projekt vom LHC ein neues Thema auf.

Hier wurden Beschränkungen aufgehoben.

vLHCathome-dev: Project Configuration Update
As we now have multiple applications, some of you have requested that we remove the restriction that limits the number running tasks per host to one. This restriction has was put in place so as not to overload machines while developing. As everyone in this development project is (or should be) an advanced user, we assume that everyone knows how to adjust their preferences to limit tasks on the client if needed. This update will be done tomorrow morning at around 10am CET (8am GMT, 1461052800 UTC).
18.04.2016 21:38:52 · weiterlesen... http://lhcathomedev.cern.ch/vLHCatho...ead.php?id=192

hier laufen jetzt folgende Projekte(Testanwendungen):

CMS Simulation:
LHCb Simulation:
Theory Simulation:
ATLAS Simulation:
ALICE Simulation:

Beispiel für eine app_config.xml

<app_config>
<project_max_concurrent>x</project_max_concurrent>
<app>
<name>ATLAS</name>
<max_concurrent>x</max_concurrent>
</app>
<app>
<name>CMS</name>
<max_concurrent>x</max_concurrent>
</app>
<app>
<name>LHCb</name>
<max_concurrent>x</max_concurrent>
</app>
<app>
<name>Theory</name>
<max_concurrent>x</max_concurrent>
</app>
</app_config>

[HJL]

ich weiß zwar nicht genau, von wann diese Nachricht ist, für mich kam das
dann halt doch etwas überraschend .....

Fakt ist, das bei meinen 3 Maschinen, wo LHC-dev läuft, natürlich sofort WUs gezogen
wurden und auch versucht wurde diese zu rechnen, 10 virtuelle Maschinen wurden auf
jedem dieser Rechner versucht zu starten, jeder kann sich nun vorstellen, was das für Konsequenzen
hatte, 2 Rechner sind kpl. abgesemmelt und einfach neu gestartet, I7/12 Kerne - leider nur je 12 GB RAM, der
3. Rechner hat's überlebt, da liefen doch glatt 10 VM´s +1, die noch von mir kommt,
aber 29 von 32 GB RAM belegt, richtig cool sowas, zum Feierabend ........
Projekt erst mal gestoppt, muss mich einlesen .....

hl

[XSmeagolX]

Ohje...

Ich töste dich mal und nehm dich liebevoll in die Arme!

[AxelS]

Ich fürchte, da muß man die Tasks begrenzen mittels app_config.xml .

[HJL]

Ich fürchte, da muß man die Tasks begrenzen mittels app_config.xml .

jep, genau so hätte ich es dann auch getan, wäre es mir denn zeitnah zu Ohren/Augen gekommen,
aber gestern Abend verkünden und 10h später schon umsetzen .... ,
wenn sonst auch immer mal alles so schnell ginge.

hl

[pilotpirx]

so wie es aussieht ist wieder die Spassbremse an, bekomme auf einem Rechner nur noch 5 Wu gleichzeitig dann meint er tasklimit erreicht.

[pschoefer]

Beim LHC-Testprojekt wird nun eine neue ATLAS-Anwendung getestet, die ohne VirtualBox auskommt. Es handelt sich dabei um die gleiche Anwendung, die sonst in der vbox läuft, daher wird nur Linux unterstützt und die komplette CERN-Umgebung muss vorher auf dem Rechner eingerichtet werden. Daher sind normale Benutzer zwar auch zum Testen eingeladen, die Zielgruppe für diese Anwendung sind aber Rechner an mit dem CERN verbundenen Instituten.

Neue native Linux-ATLAS-Anwendung
Hallo zusammen,

wenn ihr nicht Linux verwendet, könnt ihr den Rest dieses Beitrags ignorieren. Ansonsten seid ihr möglicherweise daran interessiert, die experimentelle ATLAS-Anwendung auszuprobieren, die nicht VirtualBox verwendet, sondern nativ auf Linux läuft.

WICHTIG!! Um diese Anwendung auszuführen, müsst ihr CVMFS (CERN VM File System) installieren und für ATLAS konfigurieren. Dieses Dateisystem enthält sämtliche Software für ATLAS-WUs und steckt normalerweise in der virtuellen Maschine (genau wie bei allen anderen LHC-vbox-Anwendungen).

Eine einfache Installationsanleitung ist hier zu finden: https://cernvm.cern.ch/portal/filesystem/quickstart (engl.)

Ihr solltet die Paketquellen so einstellen wie in dem Beispiel für ATLAS gezeigt. Wenn ihr einen Squid-Proxy zur Hand habt, könnt ihr ihn dort angeben - ich bin mir nicht sicher, ob es auch ohne Squid-Proxy funktioniert.

Unsere Zielgruppe für diese Anwendung sind Institute mit Verbindung zum CERN oder ATLAS, die untätige Rechner haben, auf denen CVMFS bereits installiert ist, und wir erwarten nicht, dass der durchschnittliche Freiwillige CVMFS installiert und diese Anwendung laufen lässt. Aber ich denke, dass ihr alle hier überdurchschnittliche Freiwillige seit () und daran interessiert sein könntet, es auszuprobieren.

Bitte gebt Rückmeldungen im ATLAS-Forum. Leider gibt es keine Möglichkeit, beim Anfordern neuer Aufgaben zu prüfen, ob CVMFS auf dem Rechner installiert ist, also könntet ihr diese WUs auch bekommen, wenn ihr kein CVMFS habt, und diese werden sofort abbrechen. Wählt daher die ATLAS-Anwendung besser ab, wenn ihr sie nicht laufen lassen wollt.
23.02.2017, 16:48:35 MEZ

Originaltext:

New native Linux ATLAS application
Hi all,

If you don't use Linux you can ignore the rest of this post. If you do you may be interested in trying the experimental ATLAS app which doesn't use virtualbox but runs natively on Linux.

IMPORTANT!! To run this app you must install CVMFS, the CERN VM File System, and configure it for ATLAS. This file system contains all the software for ATLAS WU and is normally inside the virtual image (the same as for all LHC vbox apps).

A simple installation guide can be found here: https://cernvm.cern.ch/portal/filesystem/quickstart

You should set up the repositories as shown in the example for ATLAS. If you have a squid proxy handy you can specify it there - if not I'm not sure whether it will work or not without configuring one.

Our target for this app is CERN or ATLAS-related institutes who have idle machines with CVMFS already installed, and we do not expect the average volunteer to install CVMFS and run this app. But I think all of you here are above-average volunteers and you may be interested in trying it.

Please give feedback on the ATLAS forums. Unfortunately there is no way to check for CVMFS on the client before requesting tasks, so if you don't have CVMFS you can still get these tasks and they will fail straight away. So better to uncheck the ATLAS app if you don't want to run it.
23 Feb 2017, 15:48:35 UTC

[pschoefer]

Eine sehr sinnvolle Funktion im Umgang mit mehreren CPU-Kernen für eine vbox-WU wird beim LHC@home-Testprojekt erprobt:

Herunterfahren von Mehrkern-VMs
Eine neue Funktion zum Herunterfahren von Multicore-VMs am Ende ihrer Lebenszeit, wenn die Leerlaufzeit die Arbeitszeit übersteigt, wurde implementiert. Das bedeutet, dass diese Aufgaben abgebrochen werden, wenn wir mehr Zeit mit leeren Kernen vergeuden als wir durch das Abbrechen der noch laufenden Aufgaben verlieren würden. Das sollte Situationen vermeiden, in denen eine in einer Schleife befindliche Theory-Aufgabe die VM beschäftigt hält, während leergelaufene Kerne verschwendet werden. Wenn es funktioniert, sollte die folgende Meldung in der Ausgabedatei erscheinen.

Multicore Shutdown: Idle > Busy ( 1439s > 1382s )

Lasst mich wissen, wie es läuft.
12.09.2017, 14:07:26 MEZ

Originaltext:

Multicore Shutdown
A new feature has been implemented to shutdown multicore VMs at the end of their life when the idle time > busy time. This means that if we are wasting more time with empty cores than we would loose by kill the remaining jobs, those jobs are killed. This should avoid the situation where a looping Theory job keeps the VM alive while wasting idle cores. If this works the following message should be seen in the task output.

Multicore Shutdown: Idle > Busy ( 1439s > 1382s )

Let me know how it goes.
12 Sep 2017, 13:07:26 UTC

[pschoefer]

Zum Test des neuen Speichersystems werden beim LHC@home-Testprojekt vermehrt ATLAS-WUs verteilt:

ATLAS-Lasttests
Zur Information: Wir haben als Teil einer Kampagne zum Test unseres neuen Speicher-Unterbaus beim Testprojekt die WU-Limits pro Rechner erhöht.

Es ist zu erwarten, dass die meisten neuen ATLAS-Aufgaben von den Rechnern unseres lokalen Clusters und des LCG-Clusters in Peking heruntergeladen werden. Aber für Interessierte gibt es auch WUs für andere Anwendungen. Es könnte auch zu Unterbrechungen kommen, da dies unser Entwicklungs- und Testsystem ist.
27.01.2018, 16:49:29 MEZ

Originaltext:

ATLAS load tests
For information: We have increased limits pr. host on the dev project as part of a campaign to test our new storage backend.

Expect most new ATLAS tasks to be pulled by our local cluster hosts and the LCG cluster in Bejing. But there are tasks for other applications too for those interested. There might be interruptions too, as this is our development and testbed. :-)
27 Feb 2018, 15:49:29 UTC

[JayPi]

Aktuell bin ich hier mit ATLAS Simulation aktiv. Die WUs laufen und Credits gibt es auch
Folgende Erfahrungen habe ich hier gesammelt:

Positiv:
Es läuft je Rechner nur noch eine WU! Diese WU nimmt sich soviele Kerne, wie in Bei mehreren Prozessoren, nutze höchstens angegeben, das finde ich sehr gut gelöst.

Negativ:
Initialdownload ca. 600M, jede WU nochmal 300M extra für ca. 1-3 Stunden Laufzeit.
Beim Download fällt mir auf, dass immer wieder der Download einfach stecken bleibt und nichts mehr für dieses Projekt geladen wird. Ein Nachstarten des Downloads in BOINC ist nicht möglich. Abhilfe bringt nur noch ein Neustart von BOINC oder das Netzwerk für ca. 1 Minute zu trennen. Dann startet der Download an der Stelle, wo er vorher eingeschlafen ist. Der Upload läuft dagegen etwas zuverlässiger.
Da ich keine Lust habe regelmäßig bei allen (Remote-)Rechnern BOINC neu zu starten oder das Netzwerkkabel zu ziehen, habe ich einen Windows Scheduler-Task eingerichtet, der alle 30 Minuten vorübergehend das Netzwerk deaktiviert (Als Administrator ausführen), um stecken gebliebene Downloads wieder zu reaktivieren.

Hier die Batch Datei:

netsh interface set interface LAN-Verbindung disabled
timeout /t 100
netsh interface set interface LAN-Verbindung enabled

Sicherer ist es, wenn die 3 Statements direkt im Windows Scheduler eingetragen werden, damit keine manipulierbare Batch-Datei im Filesystem liegt. Hier die 3 Statements:

Programm/Script:                  Argumente:
-------------------------------   -----------------------------------------------
C:\Windows\System32\netsh.exe     interface set interface LAN-Verbindung disabled
C:\Windows\System32\timeout.exe   /t 100
C:\Windows\System32\netsh.exe     interface set interface LAN-Verbindung enabled

[nexiagsi16v]

Verstehe ich das richtig, wenn man eine WU hat, dann sind fast 1GB an Speicher belegt (also 600 + 300)? Wenn man 10 WUs runter geladen hat, denn macht das ~3,5GB (600 +3.000) an Plattenspeicher? Was braucht so eine WU an RAM?

Was passiert wenn man wärend eine WU läuft die Bei mehreren Prozessoren, nutze höchstens verändert. Hat es direkte Auswirkung oder erst nach einem Neustart von BM, oder ist das egal, sprich die WU bleibt bei seine alten Kernanzahl?

[HJL]

@JayPi, das Phänomen mit den Downloads hatte ich zeitweise auch, eine kurze Unterbrechung der Netzverbindung (bei mir WLAN) hat da gereicht, um den Download zu vollenden .... (war recht lästig ...)
der Initialdownload ist aber höher, ich hab drei unterschiedliche WU-Typen bekommen (einmal 900MB, zweimal 600MB)

@nexiagsi16v - ja, kommt so ungefähr hin (die Zahlen), geholt werden die WUs mit einer bestimmten Anzahl an Cores und die bleiben auch bei einer nachträglichen Änderung so erhalten, mal davon abgesehen, die laufen in einer VM, da empfiehlt sich eine Änderung eigentlich generell nicht, die VM könnte eigenartig reagieren; RAM hab ich i.M. auch nicht im Kopf ...

[JayPi]

Leider startet der Download nach der Netzwerksunterbrechung nicht immer sofort, da BOINC den Download wegen der Unterbrechung pausiert. Da muss wohl noch ein Script her, um das auch anzuschieben - aber nicht jetzt.

@nexiagsi16v: Was den Ressourcenverbrauch angeht, rechne bei der Platte bei einem Bunker von 16 WUs mit rund 10 GB und beim RAM mit 7-10 GB. Laut Boincstats liegt der RAM-Verbrauch bei 9800 MB + 160 MB Virtueller Speicher.

[JayPi]

So langsam kommt bei mir Fahrt rein. Mit 6 Rechnern schaffe ich bereits über 40K am Tag. Mehr will ich meinem DSL nicht zumuten. Im Augenblick sorge ich immer für einen Bunker von fast 24h. Halbstündlich wird automatisch bei allen Rechnern um jeweils 5 Minuten versetzt das Netzwerk für 100 Sekunden getrennt und ab und zu schiebe ich den Download wieder an. Für meine Abwesenheiten muss ich das Anschieben auch noch automatisieren.

- - - Aktualisiert - - -

Ich sehe gerade HL direkt hinter mir Es gibt doch tatsächlich noch ein Projekt, wo ich vor ihm stehe und das muss ich halten

[-jb-]

Hallo und kurze Frage: Gibt es noch eine Möglichkeit sich bei dem Projekt anzumelden? Ich kann mich noch an einen Post erinnern, der beschrieb, an wem man eine Mail mit welchen Infos schicken sollte (zwecks Invitation Code). Leider kann ich diesen im LHC-dev Forum nicht mehr finden. Und einen Account über den Boinc-Manager anlegen ist auch nicht möglich.

[JayPi]

Damals habe ich eine Mail direkt nach Cern geschickt, die Adresse weiß ich nicht mehr. Wenn ich aber bei LHC-Dev suche, finde ich unter folgendem Link den Hinweis unter Restriction of new account creation dass man eine Mail an Ivan.Reid@CERN.ch schicken soll. Der Hinweis ist 3 Jahre alt, aber vielleicht ist er noch gültig.

[-jb-]

Besten Dank. Genau diesen Post hatte ich gemeint. Offensichtlich hatte ich Tomaten vor den Augen. Ich werde mal mein Glück versuchen.

[HJL]

.
.
.
Ich sehe gerade HL direkt hinter mir Es gibt doch tatsächlich noch ein Projekt, wo ich vor ihm stehe und das muss ich halten

Da wirst'e vermutlich auch bleiben, ich hab nur 3 relativ alte Rechner drauf - mehr geht bei meinem DSL zu Hause nicht,
muss jetzt schon manchmal ganz schön rudern, solche Projekte sind nicht meins ....

[JayPi]

Immerhin muss ich feststellen, dass das Downloadproblem inzwischen behoben wurde. Jetzt laufen sie durch ohne stecken zu bleiben. Die regelmäßige Netzwerktrennung habe ich daher von 30 Minütlich auf alle 4 Stunden umgestellt. Bei 1 Mio wird bei mir aber auch Schluss sein.

[taurec]

Immerhin muss ich feststellen, dass das Downloadproblem inzwischen behoben wurde. Jetzt laufen sie durch ohne stecken zu bleiben. Die regelmäßige Netzwerktrennung habe ich daher von 30 Minütlich auf alle 4 Stunden umgestellt. Bei 1 Mio wird bei mir aber auch Schluss sein.

Ich würde mal vorschlagen, dass wir uns erst noch die #1 holen, bevor wir da kürzer treten