Neue WUs bei LHC@Home!
- Ersteller TiKu
- Erstellt am
MagicEye04
Grand Admiral Special
So, die CPU ist nun endlich voll beschäftigt und die Theory brechen nicht mehr ab.
Aktuell haben sich 7Atlas und 4 Theory zu mir verirrt.
Profitiert LHC eigentlich von einem höheren CPU-Takt? Ich dümpel aktuell bei 65W herum, das ergibt so um die 2,2GHz.
Ich stell mal lieber auf 90W...
Aktuell haben sich 7Atlas und 4 Theory zu mir verirrt.
Profitiert LHC eigentlich von einem höheren CPU-Takt? Ich dümpel aktuell bei 65W herum, das ergibt so um die 2,2GHz.
Ich stell mal lieber auf 90W...
Die nativen Atlas WUs laufen bei mir schon den ganzen Tag mit minimalen Puffer.
MagicEye04
Grand Admiral Special
Die Theory scheinen keine Checkpoints zu haben. Da ist auch nach 2h und 60% CPU-Zeit=Zeit seit letztem Checkpoint.
Bei den Atlas steht einfach "-" seit dem letzten Checkpoint. Nach meinem Reboot vorhin liefen die aber bei den vorher erreichten ca. 20% weiter. Es hat allerdings wieder etliche Minuten gedauert, ehe eine Berechnung auch CPU-Last erzeugt hat.
Und nach wie vor nehmen sich die Atlas bei mir teils über 100%. 7x4+3=37
Bei den Atlas steht einfach "-" seit dem letzten Checkpoint. Nach meinem Reboot vorhin liefen die aber bei den vorher erreichten ca. 20% weiter. Es hat allerdings wieder etliche Minuten gedauert, ehe eine Berechnung auch CPU-Last erzeugt hat.
Und nach wie vor nehmen sich die Atlas bei mir teils über 100%. 7x4+3=37
MagicEye04
Grand Admiral Special
Ich komm auf über 3 Stunden.
Und das ist schon mit 3,5GHz gewesen.
Aktuell herrscht leichter Leerlauf, weil der upload sehr lange dauert.
Doppelposting wurde automatisch zusammengeführt:
Irgendwo ist noch der Wurm drin.
Die Atlas, die ich letzte Woche mit 2,5GHz gerechnet hatte, haben mit 12 CPUs 4000s gebraucht, also 42.000s CPU-Zeit. Das ergab knapp 700 punkte.
Die aktuelle Sorte sind mit 3,5GHz , 4 CPUs 12.000s gelaufen, also minimal längere 43.000s CPU-Zeit. Es gab nur 400 Punkte.
Die Optimierung scheint also bisher eine Verschlechterung bewirkt zu haben.
Die Theory laufen nur gleich schnell (trotz Taktsteigerung) und geben auch nur die gleichen Punkte.
Mal sehen, ob sich das bis morgen früh noch bessert.
Doppelposting wurde automatisch zusammengeführt:
Ich gebs auf. Aktuell haben 8 Atlas WUs 8x4=46 von meinen 32 CPUs in Beschlag.
Zuletzt bearbeitet:
MagicEye04
Grand Admiral Special
Jetzt haben auch die Theory bei mir das Problem, dass sie zu viel CPU-Zeit haben wollen. Mit 75% der Kerne pendelt es sich halbwegs bei 100% Last ein. Ich hab extra mal squid gestoppt, daran liegt es nicht.
koschi
Grand Admiral Special
Irgendwo ist noch der Wurm drin.
Die Atlas, die ich letzte Woche mit 2,5GHz gerechnet hatte, haben mit 12 CPUs 4000s gebraucht, also 42.000s CPU-Zeit. Das ergab knapp 700 punkte.
Die aktuelle Sorte sind mit 3,5GHz , 4 CPUs 12.000s gelaufen, also minimal längere 43.000s CPU-Zeit. Es gab nur 400 Punkte.
Die Optimierung scheint also bisher eine Verschlechterung bewirkt zu haben.
Lass die ATLAS native mal ein paar Tage laufen. Bei mir waren die Credit nach Umstellung von vBox auf native auch geringer, sind dann innerhalb der nächsten Tage aber angestiegen, auf das aktuelle Level von ~640 Credit. Manchmal gibt es sogar 700-800 Credit.
MagicEye04
Grand Admiral Special
Ist die CPU-Last bei Dir auch (teilweise) so hoch?
koschi
Grand Admiral Special
Ich habe mit 5 WUs zu je 4 Threads ATLAS native und einer Universe in den ersten 22 CPU Threads, sowie 2 FGRP1G in den letzten beiden Threads, Desktop, dauerhaft laufendem Chromium, Discord, boincmgr, Ethereum geth (5h CPU Zeit seit gestern) und einer Wallet ein Load average von 23,91, 24,39, 23,99 auf dem 3900X.
Irgendwie war ich heute auch schon mal bei 27, weiß aber nicht was da noch zusätzlich lief.
Irgendwie war ich heute auch schon mal bei 27, weiß aber nicht was da noch zusätzlich lief.
MagicEye04
Grand Admiral Special
Frage: Ist damit das hier gemeint?:
sudo apt-get install lsb-release
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
Ich hab mir den nächsten Rechner geschnappt, wo LHC laufen soll und hätte gern einfach nur eine Liste an Befehlen, die man durchrattern muss, da ist "manuell" irgendwie schlecht.
Daher hoffe ich, dass die Liste komplett ist.Edit: nachdem ich alle Befehle 3x habe durchlaufen lassen, klappt es nun.
Hoffentlich kommen wenigstens die Theory ohne permanente Netzwerkverbindung aus, sonst kann LHC eben nur nachts laufen.
Edit: Nee, leider nicht.
erde-m
Grand Admiral Special
Einfach der Reihe nach Copy&Paste inś Terminal
Code:
SOMPEś Rezept:
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 install cvmfs cvmfs-config-default
sudo cvmfs_config setup
sudo wget https://lhcathome.cern.ch/lhcathome/download/default.local -O /etc/cvmfs/default.local
sudo cvmfs_config reload
sudo sed -i '$ a\kernel.unprivileged_userns_clone = 1' /etc/sysctl.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 restart boinc-client@MagicEye04
Nicht wirklich sondern vieeel simpler. ^^
Auf den Link klicken und für die eigene Linux Version den passenden Client raussuchen (runterscrollen), runterladen, ausführen und damit installieren.
Die anderen Punkte eben immer schön der Reihe nach installieren
Nicht wirklich sondern vieeel simpler. ^^
Auf den Link klicken und für die eigene Linux Version den passenden Client raussuchen (runterscrollen), runterladen, ausführen und damit installieren.
Die anderen Punkte eben immer schön der Reihe nach installieren
MagicEye04
Grand Admiral Special
Das wollte ich hören, Danke.
Hat ja inzwischen geklappt. Vermutlich war der Restart von Boinc beim Kopieren verloren gegangen bei den ersten beiden Versuchen.
FritzB
Grand Admiral Special
Gibt wieder Sixtrack
koschi
Grand Admiral Special
Bei meinen ATLAS native sind die Credit von 700-800 auf 300-500 Credit gesunken, mache mit dem R9 daher auch erstmal Sixtrack.
In deinen fehlerhaften WUs meldet er Probleme mit Singularity. Ich hatte bei mir auch Probleme mit Singularity (wenn auch andere) und hatte daher die aktuellste Version selbst kompiliert, das ist recht gut dokumentiert und hat auf Anhieb geklappt.
Versionen von 3.0.3 auf die aktuellste 3.7.0 anpassen:
github.com
In deinen fehlerhaften WUs meldet er Probleme mit Singularity. Ich hatte bei mir auch Probleme mit Singularity (wenn auch andere) und hatte daher die aktuellste Version selbst kompiliert, das ist recht gut dokumentiert und hat auf Anhieb geklappt.
Doppelposting wurde automatisch zusammengeführt:
Versionen von 3.0.3 auf die aktuellste 3.7.0 anpassen:
Releases · apptainer/singularity
Singularity has been renamed to Apptainer as part of us moving the project to the Linux Foundation. This repo has been persisted as a snapshot right before the changes. - apptainer/singularity
github.com
erde-m
Grand Admiral Special
Mich wundert, das es zu Fehlern kommt und bei dann wieder nicht.
Fehler:
Durchgelaufen:
Zwischendrin dann aber auch diese Sequenz:
Ist also u.U. die falsche Version installiert?
Unter /cvmfs/atlas.cern.ch/repo/.images sind nur centos6 und 7 sowie slc6 zu finden...
P.S. Ich habe die ATLAS erstmal abgewählt, bis das Problem geklärt ist.
Fehler:
Code:
[2021-01-07 20:07:03] Using singularity image /cvmfs/atlas.cern.ch/repo/containers/images/singularity/x86_64-centos7.img
[2021-01-07 20:07:03] Checking for singularity binary...
[2021-01-07 20:07:03] Singularity is not installed, using version from CVMFS
[2021-01-07 20:07:03] Checking singularity works with /cvmfs/atlas.cern.ch/repo/containers/sw/singularity/x86_64-el7/current/bin/singularity exec -B /cvmfs /cvmfs/atlas.cern.ch/repo/containers/images/singularity/x86_64-centos7.img hostname
[2021-01-07 20:07:03] Singularity isnt working: [34mINFO: [0m Convert SIF file to sandbox...
[2021-01-07 20:07:03] [31mFATAL: [0m while extracting /cvmfs/atlas.cern.ch/repo/containers/images/singularity/x86_64-centos7.img: root filesystem extraction failed: extract command failed: exit status 1Durchgelaufen:
Code:
[2021-01-07 23:06:48] Using singularity image /cvmfs/atlas.cern.ch/repo/containers/images/singularity/x86_64-centos7.img
[2021-01-07 23:06:48] Checking for singularity binary...
[2021-01-07 23:06:48] Singularity is not installed, using version from CVMFS
[2021-01-07 23:06:48] Checking singularity works with /cvmfs/atlas.cern.ch/repo/containers/sw/singularity/x86_64-el7/current/bin/singularity exec -B /cvmfs /cvmfs/atlas.cern.ch/repo/containers/images/singularity/x86_64-centos7.img hostname
[2021-01-07 23:07:22] [34mINFO: [0m Convert SIF file to sandbox... mikemint-desktop [34mINFO: [0m Cleaning up image...
[2021-01-07 23:07:22] Singularity works
[2021-01-07 23:07:22] Set ATHENA_PROC_NUMBER=4
[2021-01-07 23:07:22] Starting ATLAS job with PandaID=4942725735
[2021-01-07 23:07:22] Running command: /cvmfs/atlas.cern.ch/repo/containers/sw/singularity/x86_64-el7/current/bin/singularity exec --pwd /var/lib/boinc-client/slots/37 -B /cvmfs,/var /cvmfs/atlas.cern.ch/repo/containers/images/singularity/x86_64-centos7.img sh start_atlas.sh
[2021-01-08 04:24:22] *** The last 200 lines of the pilot log: ***
[2021-01-08 04:24:22] "cpuTime": 11,
[2021-01-08 04:24:22] "cpuTimeTotal": 65082,
[2021-01-08 04:24:22] "externalCpuTime": 282,
[2021-01-08 04:24:22] "processedEvents": 200,
[2021-01-08 04:24:22] "trfPredata": null,
[2021-01-08 04:24:22] "wallTime": 17082
.
.Zwischendrin dann aber auch diese Sequenz:
Code:
[2021-01-08 04:24:22] LSB Version: :core-4.1-amd64:core-4.1-noarch
[2021-01-08 04:24:22] Distributor ID: CentOS
[2021-01-08 04:24:22] Description: CentOS Linux release 7.8.2003 (Core)
[2021-01-08 04:24:22] Release: 7.8.2003
[2021-01-08 04:24:22] Codename: CoreIst also u.U. die falsche Version installiert?
Unter /cvmfs/atlas.cern.ch/repo/.images sind nur centos6 und 7 sowie slc6 zu finden...
Doppelposting wurde automatisch zusammengeführt:
P.S. Ich habe die ATLAS erstmal abgewählt, bis das Problem geklärt ist.
erde-m
Grand Admiral Special
enigmation
Admiral Special
Meine erste Atlas-WU auf 8 Kernen wurde erfolgreich berechnet. Hab auch rund 950 Credits dafür erhalten.
Ich hab mich an Koschis und Sompes Einzelschritte gehalten, dann klappte es. Also ohne nochmal extra Singularity zu installieren.
Falls Interesse zum Vergleich die Stderr Ausgabe:
Ich hab mich an Koschis und Sompes Einzelschritte gehalten, dann klappte es. Also ohne nochmal extra Singularity zu installieren.
Falls Interesse zum Vergleich die Stderr Ausgabe:
Code:
...
[2021-01-09 12:46:52] CVMFS is ok
[2021-01-09 12:46:52] Efficiency of ATLAS tasks can be improved by the following measure(s):
[2021-01-09 12:46:52] The CVMFS client on this computer should be configured to use Cloudflare's openhtc.io.
[2021-01-09 12:46:52] Small home clusters do not require a local http proxy but it is suggested if
[2021-01-09 12:46:52] more than 10 cores throughout the same LAN segment are regularly running ATLAS like tasks.
[2021-01-09 12:46:52] Further information can be found at the LHC@home message board.
[2021-01-09 12:46:52] Using singularity image /cvmfs/atlas.cern.ch/repo/containers/images/singularity/x86_64-centos7.img
[2021-01-09 12:46:52] Checking for singularity binary...
[2021-01-09 12:46:52] Singularity is not installed, using version from CVMFS
[2021-01-09 12:46:52] Checking singularity works with /cvmfs/atlas.cern.ch/repo/containers/sw/singularity/x86_64-el7/current/bin/singularity exec -B /cvmfs /cvmfs/atlas.cern.ch/repo/containers/images/singularity/x86_64-centos7.img hostname
[2021-01-09 12:47:33] [34mINFO: [0m Convert SIF file to sandbox... Ryze [34mINFO: [0m Cleaning up image...
[2021-01-09 12:47:33] Singularity works
[2021-01-09 12:47:33] Set ATHENA_PROC_NUMBER=8
[2021-01-09 12:47:33] Starting ATLAS job with PandaID=4943216385
[2021-01-09 12:47:33] Running command: /cvmfs/atlas.cern.ch/repo/containers/sw/singularity/x86_64-el7/current/bin/singularity exec --pwd /var/lib/boinc-client/slots/7 -B /cvmfs,/var /cvmfs/atlas.cern.ch/repo/containers/images/singularity/x86_64-centos7.img sh start_atlas.sh
...
]]>koschi
Grand Admiral Special
@erde-m @enigmation
Hattet ihr mal versucht den Squid Cache einzurichten? Zumindest laut CVMFS Selbstauskunft wird er nicht genutzt, bei größeren Mengen ATLAS spart das Bandbreite, vor allem aber Verbindungen und schlägt damit nicht so auf die Netzwerklatenz, zudem starten die WUs schneller und sind damit effizienter.
Einrichtung hatte ich hier beschrieben, sieht viel aus, ist aber in 5 Minuten gemacht.
forum.planet3dnow.de
Hattet ihr mal versucht den Squid Cache einzurichten? Zumindest laut CVMFS Selbstauskunft wird er nicht genutzt, bei größeren Mengen ATLAS spart das Bandbreite, vor allem aber Verbindungen und schlägt damit nicht so auf die Netzwerklatenz, zudem starten die WUs schneller und sind damit effizienter.
Einrichtung hatte ich hier beschrieben, sieht viel aus, ist aber in 5 Minuten gemacht.
Neue WUs bei LHC@Home!
Die Theory WUs (native) scheinen einen deutlich erhöhten CPU-Verbrauch zu haben. :( Ich musste im BM auf 80% runtergehen, damit nicht 37 von 32 Kernen voll ausgelastet sind - was die anderen Projekte massiv ausbremst.
forum.planet3dnow.de
enigmation
Admiral Special
Hallo @koschi
danke für die Anleitung.
Ich hab das in der Stderr Ausgabe gelesen, ja, hatte es für mich aber als nicht relevant abgetan, da ja LAN da stand:
Du meinst, das lohnt sich mit dem Squid-proxy auch dann, wenn man nur einen Linuxrechner hat, aber parallel mehrere Atlas laufen, also z.B. 3x4Core auf meinem 1700x?
Dann kann ich das ja einmal ausprobieren, muss nur noch erst einmal ein paar Vergleichswerte berechnen, um zu sehen, ob und wie es mit dem Squid-Proxy besser läuft...
Vielen Dank!
danke für die Anleitung.
Ich hab das in der Stderr Ausgabe gelesen, ja, hatte es für mich aber als nicht relevant abgetan, da ja LAN da stand:
Code:
[2021-01-09 12:46:52] Small home clusters do not require a local http proxy but it is suggested if
[2021-01-09 12:46:52] more than 10 cores throughout the same LAN segment are regularly running ATLAS like tasks.Dann kann ich das ja einmal ausprobieren, muss nur noch erst einmal ein paar Vergleichswerte berechnen, um zu sehen, ob und wie es mit dem Squid-Proxy besser läuft...
Vielen Dank!
koschi
Grand Admiral Special
Ist vielleicht grenzwertig der Anwendungsfall, laut LHC empfiehlt es sich ab "10 cores". Die Empfehlung stammt sicher aus Zeiten als 10 cores idR. noch mehrere Maschinen waren.
Grundsätzlich gibt es wohl zwei Cache Ebenen, einmal in CVMFS, einmal in Squid.
Die CVMFS Installation gibt es ja pro Rechner oder VM nur einmal, sie cached "files and meta data". Innerhalb der VM sind sämtliche heruntergeladenen Sachen im Cache des CVMFS natürlich mit dem Ende der WU wieder weg. Davon ab scheint das CVMFS auch nicht alles zu speichern, mein zusätzlich laufender Squid Cache zeigt auch schon einen Platzverbrauch von 7GB in 5700 Objekten. Der Squid ergänzt also den CVMFS Cache und macht insbesondere auf Systemen mit ATLAS vBox WUs Sinn, da diese WUs nicht von den Downloads der vorherigen WUs profitieren können und demnach alles mehrfach ziehen. Der externe (Squid) Cache wird im BOINC Client (über boincmgr oder cli) konfiguriert und dann beim Start der vBox WU dem virtuellen System übergeben, damit diese darauf zugreifen kann.
Jede startende ATLAS WU zieht hunderte bis tausende Files aus dem Netz nach, das access.log des Squid Caches rattert dann die einzelnen Zeilen in rasanter Geschwindigkeit herunter.
Grundsätzlich gibt es wohl zwei Cache Ebenen, einmal in CVMFS, einmal in Squid.
Die CVMFS Installation gibt es ja pro Rechner oder VM nur einmal, sie cached "files and meta data". Innerhalb der VM sind sämtliche heruntergeladenen Sachen im Cache des CVMFS natürlich mit dem Ende der WU wieder weg. Davon ab scheint das CVMFS auch nicht alles zu speichern, mein zusätzlich laufender Squid Cache zeigt auch schon einen Platzverbrauch von 7GB in 5700 Objekten. Der Squid ergänzt also den CVMFS Cache und macht insbesondere auf Systemen mit ATLAS vBox WUs Sinn, da diese WUs nicht von den Downloads der vorherigen WUs profitieren können und demnach alles mehrfach ziehen. Der externe (Squid) Cache wird im BOINC Client (über boincmgr oder cli) konfiguriert und dann beim Start der vBox WU dem virtuellen System übergeben, damit diese darauf zugreifen kann.
Jede startende ATLAS WU zieht hunderte bis tausende Files aus dem Netz nach, das access.log des Squid Caches rattert dann die einzelnen Zeilen in rasanter Geschwindigkeit herunter.
Zuletzt bearbeitet:
enigmation
Admiral Special
Danke für deine Erklärung, koschi.
Ich rechne die ATLAS Simulation 2.85 (native_mt), also nativ mit dem CVMFS installiert in meinem Linux Mint.
Es waren vorhin so 300MB Upload und 550MB Download bei einer Atlas-WU. Das hat bei mir ca. eine Minute gedauert. Wenn es um diese Minute für den Squid-Proxy nur geht - lohnt dann der Aufwand?
Vielleicht ja während serverseitig ungünstiger Bedingungen wie während einer Challenge wie dem Pentathlon kann das ein Vorteil sein.
Ich rechne die ATLAS Simulation 2.85 (native_mt), also nativ mit dem CVMFS installiert in meinem Linux Mint.
Es waren vorhin so 300MB Upload und 550MB Download bei einer Atlas-WU. Das hat bei mir ca. eine Minute gedauert. Wenn es um diese Minute für den Squid-Proxy nur geht - lohnt dann der Aufwand?
Vielleicht ja während serverseitig ungünstiger Bedingungen wie während einer Challenge wie dem Pentathlon kann das ein Vorteil sein.
erde-m
Grand Admiral Special
@koschi
Danke für Deine erhellenden Hintergrundinfos
Ich vermute da auch die Netzwerkverbindung als eine mögliche Ursache für meine sporadischen, aber zeitlich eng zusammen liegenden Atlas-Probleme. Als beide Maschinen LHC only mit 152 Kernen liefen, habe ich meine Netzstruktur schon ändern müssen, damit ich keine Aussetzer beim IPTV habe. Da ging schon gut was über die 200/40 MBit-Leitung.
Da werde ich mich mal noch an die Squid-Einrichtung machen... vorher bekommt aber der V12 noch Singularity 3.7 verpasst.
P.S. Ich habe die Anleitung Deiner Links genutzt und gleich direkt 3.7. gezogen und kompiliert.
PPS. Jetzt bekommt der 3900x natürlich nur Sixtrack vom Server serviert, also aktuell kein Test möglich (ich will die Sixtrack jetzt nicht deaktivieren, damit uns SG nicht noch weiter enteilt) Eine entsprechend angepasste app-config.xml muss da also auch noch her.
@enigmation
Ich habe Altas nativ mit 4 Kernen/WU zwischen ca. 620 (CPU-Zeit 32.000s) und 950 Credits (CPU-Zeit 52.000s).
Die 4 Kerne haben sich mMn als Optimum bezüglich der Credit-Ausbeute herausgestellt.
Danke für Deine erhellenden Hintergrundinfos
Ich vermute da auch die Netzwerkverbindung als eine mögliche Ursache für meine sporadischen, aber zeitlich eng zusammen liegenden Atlas-Probleme. Als beide Maschinen LHC only mit 152 Kernen liefen, habe ich meine Netzstruktur schon ändern müssen, damit ich keine Aussetzer beim IPTV habe. Da ging schon gut was über die 200/40 MBit-Leitung.
Da werde ich mich mal noch an die Squid-Einrichtung machen... vorher bekommt aber der V12 noch Singularity 3.7 verpasst.
P.S. Ich habe die Anleitung Deiner Links genutzt und gleich direkt 3.7. gezogen und kompiliert.
Doppelposting wurde automatisch zusammengeführt:
PPS. Jetzt bekommt der 3900x natürlich nur Sixtrack vom Server serviert, also aktuell kein Test möglich (ich will die Sixtrack jetzt nicht deaktivieren, damit uns SG nicht noch weiter enteilt) Eine entsprechend angepasste app-config.xml muss da also auch noch her.
Doppelposting wurde automatisch zusammengeführt:
@enigmation
Ich habe Altas nativ mit 4 Kernen/WU zwischen ca. 620 (CPU-Zeit 32.000s) und 950 Credits (CPU-Zeit 52.000s).
Die 4 Kerne haben sich mMn als Optimum bezüglich der Credit-Ausbeute herausgestellt.
Zuletzt bearbeitet:
Ähnliche Themen
