Neue WUs bei LHC@Home!

Von drehender Platte würde ich absehen, die Dateien im Cache sind sehr klein, da wird nicht viel am Stück gelesen.

Ich hatte mir die cvmfs Installation & Konfiguration im November in einer Datei abgelegt und so auf verschiedenen Rechnern ausgerollt, lief überall dann auch problemlos. Nachdem einige ja nun neuinstalliert worden waren klappt das nicht mehr, die von cvfms_config probe gezeigten Einträge zeigen alle Failed. Ich muss mal gucken ob das LHC Forum dazu was hergibt.

Das Engagement des Moderators ist lobenswert, grundsätzlich finde ich aber das LHC aktiver (früher) und umfassender informieren könnte. Das könnte im Profil mit einem Link direkt neben der "Use native when available" Checkbox zum aktuellen cvmfs & Squid Setup beginnen, oder meinetwegen zu einer Übersichtsseite für Dummies und Max Mustermann den Durschnittsboincer. Kurze Darstellung der Architektur, welche Komponenten sind relevant, was genau ist zu tun.

Einigen Nutzern eines 128 Thread Systems wird die hohe Netzlast nicht auffallen, andere kommen evtl. von selbst drauf das es an LHC liegt, aber sehen die Möglichkeiten zur Optimierung nicht. Letztendlich ist so ein Prozessor dann auch nicht schneller als vier 3950X, die unter Enthusiasten verbreitet sind. Wenn schon 4 Enthusiaten das Projekt zum schwitzen bringen, sollte man die Infos vielleicht nicht nur in irgendwelchen nicht mehr änderbaren Forenthreads ablegen.
Systeme mit vielen Cores sind beliebt, die angesprochenen 10 worker (was ist das genau? Ich gehe davon aus es sind Threads gemeint) hat ja nun mitlerweile jeder Mittelklasseprozessor, zunehmend selbst einige Notebooks.
Demnach müsste die Empfehlung für jeden ATLAS (native) Cruncher lauten: Squid installieren & konfigurieren, CVMFS anpassen.
Das muss irgendwo deutlich stehen. Hinterher nur den großen Jungs auf die Pfoten zu hauen beseitigt die Ineffizienzen bei den kleineren auch nicht.
 
Irgendetwas haut da mit der Einstellung "Maximale Anzahl CPUs" nicht hin.
Sobald ich etwas anderes als "keine Einschränkung" eintrage, werden solange keine neuen WUs nachgezogen,
bis der Wert erreicht ist, und da bleibt es auch.
Um mich komplett zu verunsichern, kommt folgende Meldung im Boincmanager:
Code:
Sa 20 Feb 2021 21:21:15 CET | LHC@home | No tasks are available for SixTrack
 
Von drehender Platte würde ich absehen, die Dateien im Cache sind sehr klein, da wird nicht viel am Stück gelesen.
Bei den Mengen ist eine gute SSD wohl besser.
Demnach müsste die Empfehlung für jeden ATLAS (native) Cruncher lauten: Squid installieren & konfigurieren, CVMFS anpassen.
Das muss irgendwo deutlich stehen. Hinterher nur den großen Jungs auf die Pfoten zu hauen beseitigt die Ineffizienzen bei den kleineren auch nicht.
Zumal es sehr wahrscheinlich wesentlich mehr von den "kleinen" Crunchern gibt. Mit dem aktuellen Run auf die 8/16-und 12/24-Kerner wird das Problem noch größer werden.
Wenn computezrmle nicht merkt, dass das Stückwerk an Infos über mehrere Freds verteilt, für ihn mehr Arbeit macht als einmal das als Zusammenfassung prominent zu platzieren, dann hat er eben mehr Arbeit ;)

Wir können das natürlich auch gut in unseren DC-Wiki ausarbeiten und im LHC-Forum einstellen und verlinken...*buck*
Irgendetwas haut da mit der Einstellung "Maximale Anzahl CPUs" nicht hin.
Sobald ich etwas anderes als "keine Einschränkung" eintrage, werden solange keine neuen WUs nachgezogen,
bis der Wert erreicht ist, und da bleibt es auch.
Um mich komplett zu verunsichern, kommt folgende Meldung im Boincmanager:
Code:
Sa 20 Feb 2021 21:21:15 CET | LHC@home | No tasks are available for SixTrack

LHC lasse ich immer unbegrenzt laufen. Ich musste bisher eher andere parallel laufende Projekte begrenzen, damit die sich nicht alles geschnappt haben, egal wie die Deadline der LHC aussah. Da scheint es im BM noch Probleme zu geben + das Problem der fehlenden WU-Verteilung an Threadmonster seitens der Projektbetreiber.
 
Mein Erkenntnisgewinn für dieses Wochenende besteht darin, dass mit 2 Cluster-Rechnern die Upload-Bandbreite
der Mobilfunkverbindung ausgereitzt ist. Na gut, wir reden ja hierbei immerhin von 512 Threads. ;D
 
Reicht doch aktuell aus *great*
 
Ich würde gerne meine Up- und Down-Loads auf die Vormittagsstunden verlegen, weil dann die Datengeschwindigkeit mit dem Projekt um einiges höher ist.
Nur will das Projekt mir maximal eine Reserve-WU rausrücken. Macht das einen Unterschied, ob ich Sixtrack oder ATLAS rechne?
Zur jetzigen Tageszeit rechnet das System schneller, als es ATLAS-WUs nachladen kann.
1/3 der Threads hat Arbeit. Tendenz absteigend.

----

Warum starte ich Dullie eigentlich keine zweite Instanz? *glaubses*
Ist nur die Frage, was ich in die hosts-Datei eintragen muß?
 
Zuletzt bearbeitet:
Vor einem Monat hab ich eine Woche
  • native_theory: 0,82 Credits/Minute
  • native Atlas: 1,02 Credits/Minute
  • Sixtrack: 0,9 Credits/Minute
gerechnet unter Linux. Die üblichen Schwankungen berücksichtigend ist es also gehupft wie gesprungen, was du nimmst.
 
Sixtrack:
Code:
koschi@frickelbude:~$ get_validated "https://lhcathome.cern.ch/lhcathome/results.php?hostid=10609806&offset=0&show_names=0&state=4&appid=1"
0 20 40 60 80 - download complete. Calculating...
Application:                              SixTrack
CPU:           AMD Ryzen 9 3900X 12-Core Processor
OS:                Linux Ubuntu Ubuntu 20.04.2 LTS
Results fetched:                               100
Average duration (s):                       7836.4
Average credit:                              92.62
Number of reported cores:                       24
Per core per day:                             1018
Per system per day:                          24432

CMS simluation:
Code:
koschi@frickelbude:~$ get_validated "https://lhcathome.cern.ch/lhcathome/results.php?hostid=10609806&offset=0&show_names=0&state=4&appid=11"
0 20 40 60 - download complete. Calculating...
Application:                        CMS Simulation
CPU:           AMD Ryzen 9 3900X 12-Core Processor
OS:                Linux Ubuntu Ubuntu 20.04.2 LTS
Results fetched:                                49
Average duration (s):                      42789.4
Average credit:                             466.46
Number of reported cores:                       24
Per core per day:                              932
Per system per day:                          22368

ATLAS Simluation (native):
Code:
koschi@frickelbude:~$ get_validated "https://lhcathome.cern.ch/lhcathome/results.php?hostid=10609806&offset=0&show_names=0&state=4&appid=14"
0 20 40 60 80 - download complete. Calculating...
Application:                      ATLAS Simulation
CPU:           AMD Ryzen 9 3900X 12-Core Processor
OS:                Linux Ubuntu Ubuntu 20.04.2 LTS
Results fetched:                               100
Average duration (s):                      54296.3
Average credit:                             658.91
Number of reported cores:                       24
Per core per day:                              988
Per system per day:                          23712

Den non-Sixtrack kannst du den Netzwerkzugriff aber nicht verbieten, dann pausieren die. Über /etc/hosts führt das vermutlich zu Abbrüchen, wenn benötigte Inputs für die WUs nicht geladen werden können. Würde ich von absehen.
 
Up- und Down-Load haben sich wieder eingeregelt. Jetzt läuft wieder alles normal.
 
ich bin heute von einem LHC-Mod, mit dem ich gerade "privat" gemailt hatte, angeschrieben worden...
Ich erinnere mich mit Schrecken an die Bastelei mit dem Proxy.
Noch mal möchte ich das nicht machen.
Wäre es da nicht sinnvoller, wenn seitens des Projektes ein lokaler Cache für die Daten angelegt wird? Das sollte doch locker in den RAM oder eine Datei auf der Festplatte passen. So müssen sämtliche User diesen Workaround implementieren, anstatt dass es nur einer mal direkt im Projekt macht.
 
Mit lokal meinst du auf Projektserverseite? Dann muss es ja trotzdem noch durch deren WAN Verbindung, die wird dann wohl seitens LHC aber schnell zum Flaschenhals.

Daher versuchen sie Teile der Daten außerhalb ihres Netzes auszulagern und versuchen so viele Daten wie möglich in der Nähe der "worker" bereit zu halten. Da ergänzen sich mehrere Maßnahmen:

Code:
[ LHC Projekt und HPC Server ]
 /\
/||\
 ||                WAN link
\||/
 \/
Nutzung von openHTC.io (nutzt cloudflare im Hintergrund)
 /\
/||\
 ||             WAN link
\||/
 \/
Unsere Squid Caches
 /\
/||\
 ||                LAN
\||/
 \/
den internen Cache von CVMFS

Der Pfeil vom CVMFS zum OpenHTC müsste wohl am Squid vorbeilaufen, bin aber zu faul das nochmal umzubauen. Es gibt also eine Cache Hierarchie die so schon massiv Bandbreite spart und auch genutzt werden sollte.

Ich hab CVMFS und Squid jetzt mehrfach installiert, fand die CVMFS Installation irgendwie fehleranfälliger.
Squid geht in wenigen Minuten durch. Meine Anleitung war damals vielleicht noch nicht ganz eindeutig an einigen Stellen, ich gelobe jene im Wiki dann zu verbessern.
 
Zuletzt bearbeitet:

Gerade über diesen Beitrag gestolpert der die "worker" definiert, letztendlich ist es wie vermutet die Anzahl an Threads die CMS, ATLAS oder Theory rechnen.
Die Empfehlung einen Cache einzusetzen wurde von 10 auf 5 Threads herabgesetzt, dh. wer ernsthaft LHC abseits von Sixtrack rechnen will, sollte einen Squidcache aufsetzen.
 

Das "wie" ist abgedeckt, es fehlt vielleicht noch ein wenig zum "warum" bzw. der allgemeinen Architektur. Da gucke ich mal ob ich ein frei kopierbares Schaubild finde.

@NEO83
Installation von Squid und CVMFS läuft bissl anders, die Konfiguration sollte dann aber auch für Arch passen.
 
Zuletzt bearbeitet:
Ich glaube ich kapituliere vor Arch und Atlas nativ ....
Arch ist an sich echt cool, scheinbar aber einfach nicht weit verbreitet genug bei crunchern als das es wirklich eine Anleitung dafür gibt wie man die Dinger unter Arch zum laufen bringt :/

Mal sehen ob ich mich vorerst von arch trenne oder einfach nur keine Atlas mehr rechne was aber dumm wäre aber naja


Es wäre einfacher dir zu helfen wenn du beschreiben könntest welche Schritte du erledigt hast und woran es scheitert.
Hast du die default.local heruntergeladen?
 
Ich habe bei mir wegen der Netzwerkprobleme und dem Installationsaufwand den Support für die nativen Linux WUs wieder abgeschaltet. Das ist mir einfach zu umständlich geworden und derzeit den Aufwand nicht wert, dann müssen sie bei Bedarf eben in der Vbox VM laufen.
 
Mit lokal meinst du auf Projektserverseite?
Nein, lokal beim User auf dem Rechner. Und sei es nur ein Installationsscript, was alles einrichtet, damit man nur noch zum Schluss die Adresse als Proxy eintragen muss, wenn das nicht auch per Befehl geht.
 
Ja die Dokumentation seitens des Projektes ist ausbaufähig. Sie sollte konzentriert an einer Stelle zugänglich, prominent verlinkt und verständlich für Max Mustermann den Durchschnittscruncher sein. Eine distributionsunabhängige Installationsanleitung ist sicher ohne massiven Aufwand erstell- und wartbar. Unterschiede der Distributionen kann man aufzeigen.

Ein Installationsskript hingegen, das mindestens für Ubuntu/Debian/Mint, (open)SuSE, Fedora und RedHat/CentOS/ScientificLinux in den letzten beiden noch supporteten LTS Versionen passt, wird mega komplex. Da kann man mehr falsch als richtig machen, bis das für alle passt.

Magst du dir unseren Wikiartikel zur Squid/CVMFS Installation und Einrichtung mal anschauen und vielleicht auch einmal testweise durchspielen? Umso mehr Leute den mal testen, Feedback liefern oder Fehler gleich ausbügeln, umso besser wird er.
Idealzustand sollte sein, dass der Artikel vielleicht einen Linuxeinsteiger zum native crunchen bekommt. Dafür sollte er an sich nur die Shell aufrufen und auch einen Editor bedienen können.
 
Magst du dir unseren Wikiartikel zur Squid/CVMFS Installation und Einrichtung mal anschauen und vielleicht auch einmal testweise durchspielen? Umso mehr Leute den mal testen, Feedback liefern oder Fehler gleich ausbügeln, umso besser wird er.
Idealzustand sollte sein, dass der Artikel vielleicht einen Linuxeinsteiger zum native crunchen bekommt. Dafür sollte er an sich nur die Shell aufrufen und auch einen Editor bedienen können.
Wenn ich Zeit habe am WE werde ich wohl den einen Rechner von mir am WE platt machen und da das aktuelle Leap 15.3 Beta (@Ritschie Testest du auch Beta?) aufspielen (aktuell läuft die 15.3 Alpha -> Wegen SiDok Race installiert).
Squid hatte ich davor schon laufen wegen lahmer Internetleitung.
Das versuch ich dann mal nach Handbuch zu installieren.
 
Soderle ... das ist alles nicht so einfach wie gehofft, ich hab cvmfs über AUR installiert und noch mal im LHC Forum gefragt, dort sagt man mir aber nur was ich weiß und helfen kann / will da vllt auch nicht wirklich jemand :P

Wie gesagt, cvmfs über AUR installiert und dann mir das debain package von cvmfs-config-default geladen, mit debtap in ein für arch nutzbares Format umgewandelt ... funktioniert auch alles ohne Probleme und lies sich installieren.
Leider ist es so, das cvmfs und cvmfs-config-default nicht gleichzeitig installiert sein können ^^
Warum das so ist, kann ich leider nicht sagen und im Fehlerbericht in der Konsole steht auch nichts :/

Code:
: cvmfs und cvmfs-config-default stehen miteinander in Konflikt. cvmfs-config-default entfernen? [j/N] n
Fehler: Nicht auflösbare Paketkonflikte gefunden
Fehler: Konnte den Vorgang nicht vorbereiten (In Konflikt stehende Abhängigkeiten)
:: cvmfs und cvmfs-config-default stehen miteinander in Konflikt

Es gibt im LHC Forum EINEN der nachweislich wohl cvmfs unter arch mit ATLAS ans laufen gebracht hat, allerdings hat er leider nicht ausgeführt wie er das hinbekommen hat, ich hab den mal angeschrieben :)


Achso, beim lesen habe ich folgendes gefunden:


Die Frage ist ob man dadurch quasi die ATLAS auch nativ unter Windows zum laufen bekommt, denn voraussetzung ist ja erst mal cvmfs wenn ich das so richtig verstanden habe.
Ich vermute das es nicht geht denn als wenn ich der erste wäre der das liest und dem das auffällt :P
 
(@Ritschie Testest du auch Beta?)
Eigentlich eher nicht. Bin mit der openSUSE Leap 15.2 derzeit so zufrieden, dass ich für mich aktuell keinen Sinn sehe. Bin gerade zu 100% bei LHC@SixTrack. Never touch a running system :-)

Für SiDock würde es aber wohl durchaus Sinn machen - danke für den Hinweis!

Gruß
Ritschie
 
Bei Sixtrack hat es sich wohl erstmal ausgesixtrackt :-D
 
Was lange wehrt wird endlich gut, ich habe es tatsächlich ans laufen gebracht und es ist noch viel viel einfacher als alle denken :P
Ich mache später eine Anleitung fertig wie man die nativen WUs von LHC auf Arch zu laufen bekommt und das auch noch ohne viel Aufwand :)
Will aber eben sicher gehen das sie wirklich problemlos laufen und nicht doch irgendwo hängen bleiben
Doppelposting wurde automatisch zusammengeführt:

So ich plotter das hier mal rein als code der eingegeben werden muss :)


Code:
$ pacman -S paru
$ paru cvmfs
$ cvmfs_config setup
$ pacman -S autofs

# Manuell über die Dateiverwaltung einen SymLink von "/etc/auto.cvmfs" nach "/usr/lib/cvmfs/auto.cvmfs erstellen

$ paru singularity-container
$ reboot

$ cvmfs_config probe
# folgendes ergebnis muss zurückgemeldet werden:
Probing /cvmfs/atlas.cern.ch... OK
Probing /cvmfs/atlas-condb.cern.ch... OK
Probing /cvmfs/grid.cern.ch... OK
Probing /cvmfs/sft.cern.ch... OK
Probing /cvmfs/lhcb.cern.ch... OK
Probing /cvmfs/lhcbdev.cern.ch... OK

Ich hoffe man kann das verstehen

@erde-m oder co, wäre fein wenn mir noch jemand bei der Einrichtung des squid caches helfen könnte ... für sowas bin ich zu doof :/
Oder eben die Einrichtung von https://openhtc.io/
 
Zuletzt bearbeitet:
Ist alles im Wiki dokumentiert im oben verlinkten Artikel "LHC native einrichten" ...
 
Zurück
Oben Unten