Neue WUs bei LHC@Home!

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.
Die Up- und Downloadzeit der WU soweit BOINC sie sieht wird ja zu deren Laufzeit nicht hinzugezählt. Sobald die WU + Anwendung dann einen Slot kopiert/gelinked und gestartet werden, beginnt die Laufzeituhr zu ticken. Da geht dann bei ATLAS aber erst die Vorbereitungsphase los, OS container entpacken, jede Menge Zeug mounten, dann hunderte bis tausend Files ziehen bevor es überhaupt losgeht mit der Berechnung. In der Zeit wird kaum CPU-Zeit in Anspruch genommen, es lohnt sich daher diese Phase soweit als möglich zu verkürzen, sowie die Parallelität von 12 oder 8 auf 4 zu reduzieren, dann sind nicht so viele Threads idle, die Effizienz steigt.

Zu Spitzenzeiten zeigte mein access.log vom Squid 140.000 Zugriffe am Tag, rein aus BOINC, über 99% davon zum CERN hin. Bei ca. 60 ATLAS am Tag sind das pro WU 2300 Zugriffe auf das Internet. Der Großteil dieser Zugriffe wird jedoch vom Squid lokal abgefangen und beantwortet.
Im Heimnetzwerk mit gesamt 12 ATLAS Threads ist das noch kein Problem. Für den Cluster mit über 1000 Threads blieben jedoch selbst mit Squid noch soviele parallele Kleinstverbindungen übrig, dass die Netzwerklatenz im LAN übel einbrach, LHC auf dem Cluster daher ausfällt.

Caching der eigentlichen "BOINC WU" lohnt sich nicht, sie sind riesig und doch einzigartig, würden also kein zweites Mal aus dem Cache abgerufen werden.
 
@koschi
Ich habe testweise den 3900x mit Singularity 3.7.0 versehen, jetzt mal abwarten, was die Atlas-WU dazu sagen.
Interessanterweise gab es vorher aber keinen Fehler mehr bei den letzten WUs, welche ich noch im Bunker hatte und die fertig gerechnet wurden...
Die ersten Atlas sind durch - es funzt :-)
Code:
[2021-01-10 15:35:42] Using singularity image /cvmfs/atlas.cern.ch/repo/containers/images/singularity/x86_64-centos7.img
[2021-01-10 15:35:42] Checking for singularity binary...
[2021-01-10 15:35:42] Using singularity found in PATH at /usr/local/bin/singularity
[2021-01-10 15:35:42] Running /usr/local/bin/singularity --version
[2021-01-10 15:35:42] singularity version 3.7.0
[2021-01-10 15:35:42] Checking singularity works with /usr/local/bin/singularity exec -B /cvmfs /cvmfs/atlas.cern.ch/repo/containers/images/singularity/x86_64-centos7.img hostname
[2021-01-10 15:35:42] mike-mint-3900x
[2021-01-10 15:35:42] Singularity works
 
Könnte man nicht auch so einen Squid auf nem Raspberry4 montieren und somit mehrere Rechner im LAN versorgen. Das sollte doch nochmals Bandbreite einsparen?
 
Ja mehrere Rechner an einem Squid ist empfehlenswert, dann profitieren die auch jeweils von den Daten die die anderen schon mal gebraucht haben.
Ich würde das Cacheverzeichnis /var/cache/squid und womöglich auch das log file aber auf eine über USB angeschlossene SSD packen, sonst tust du der SD Karte keinen Gefallen. Mit den vermutlich 2 oder 4GB RAM lässt sich ein gewachsener Cache auch nicht vollends im RAM halten, daher lieber ein schnelles und zuverlässiges Speichermedium nutzen.
 
@Landjunge
Gute Idee!
Ich wollte ohnehin anfangen mal mit nem Raspi rumzuspielen ... Bewässerungssteuerung für den Garten ;-)
da kann ich so schon mal Erfahrung sammeln - Fragen an die Runde garantiert *buck*
 
Ich dachte ja auch ich bin nen Schlauer und mache auf der Synolgy Diskstation den Proxy an. Dann über BoincTasks beim jeweiligen Rechner nen HTTP Proxy eingestellt. Nur leider geht der HTTPS Kram dran vorbei. Naja, LHC sind meine Kisten eh grad nicht bei.
 
Die Schedulerkommunikation usw. mag über https stattfinden, schaue ich aber in die client_state.xml, dann verweisen alle download_url von LHC bei mir aber auf http Server. Obwohl das Projekt via https angemeldet ist.
 
V12 und 3900x sind mit Singularity 3.7 und Squid versorgt.
V12 funktioniert problemlos - gestiegene Effizienz sieht man schon deutlich in den Stats ;-)
Squid auf den 3900x hackt noch etwas, muss ich noch Ursache finden

@koschi
Vielen Dank für die Unterstützung auch per PN *great*
 
Irgendwie sinken die Credits für die Atlas seit 2 Tagen. Gab es bei ca. gleicher Rechenzeit noch 650 Credits sind es aktuell 450 Credits.
Ist bekannt welche Faktoren in die Berechnung einlaufen?
Oder muss man mit jedem Restart des Rechners einmal einen neuen Benchmarklauf machen?
 
Ja, das kann ich auch feststellen. Aber gleichzeitig sinkt auch die benötigte CPU-Zeit (Summe aller Kerne) entsprechend.
 
Hatte ich vor wenigen Tagen auch, hatte ATLAS dann zugunsten von Sixtrack pausiert.
Seit vorgestern wieder aktiviert sind meine Credits bei 600-750 aktuell pro WU. Keine Ahnung woran die das letztendlich festmachen, Laufzeit wird nur ein Teil der Gleichung sein.
 
Ich habe noch folgenden ergänzenden Hinweis erhalten, die cvmfs_config betreffend:

Code:
Squid läuft, aber die CVMFS-Server noch auf Stratum 1 verweisen.
Das liegt möglicherweise an einer Ergänzung, die die Entwickler im September 2020 freigegeben haben und die noch nicht hier im Forum diskutiert wurde.

Bitte schreib' mal folgende Zeile in die Datei /etc/cvmfs/default.local:

CVMFS_USE_CDN=yes


Nach dem Abspeichern ein "cvmfs_config reload".

Bei "cvmfs_config stat" sollte jetzt "...openhtc.io" statt "cvmfs-stratum-one.cern.ch" in der Ausgabe stehen.


NB:
Das betrifft nur CVMFS.
Frontier wird direkt über die Setup-Scripte der Tasks konfiguriert und da solltest du openhtc.io bereits im acces.log deines Squid sehen:

http://atlascern-frontier.openhtc.io:8080/atlr/...

Habe ich entsprechend ergänzt, "cvmfs_config reload" und seither läuft es entsprechend.
 
Danke, hab ich bei mir auch mal gesetzt.
 
Sixtrack sind mal wieder durch, ich versuche mein Glück nochmal an den ATLAS...
 
Ich habe gerade mal noch 25 Sixtrack in Bearbeitung und 255 im Pending. Mal sehen wie weit der Boost noch reicht ;-)

Der V12 hat es auf P2 in der LHC-Rangliste geschafft :-)
Besser ist nur ein TR3990X mit Boinc Version 7.17 (???)
 
Es gibt wieder Sixtracks :-) *attacke*
 
Oha, Ritschie drückt mächtig auf die Tube *great* :D*attacke*
 
SiDock meint ja, mich boykottieren zu müssen, indem sie keine RxDock rausgeben (und wenn dann nur in homöopathischen Mengen) :rolleyes:

Dann geb ich halt hier Gas, wenn Sixtrack schonmal liefert bis zum Abwinken 🤗
 
SiDock meint ja, mich boykottieren zu müssen, indem sie keine RxDock rausgeben (und wenn dann nur in homöopathischen Mengen) :rolleyes:
Nee, die hat ja anscheinend jemand komplett weggesaugt und solang sie nicht reported werden, gibt es anscheinend keine Neuen.
 
Dann geb ich halt hier Gas, wenn Sixtrack schonmal liefert bis zum Abwinken 🤗
Ja, erstaunliche Menge an Sixtrack. Und bis auf einen kurzen Hänger kommen auch Atlas und Theory in ausreichender Menge nach.

---EDIT---
Der V12 hat es auf P1 geschafft :-)

Bildschirmfoto vom 2021-02-03 09-59-26.png
@Ritschie
Dein 3950X auf P12 und der TR 1950X auf P14 *great* ; der TR 3970X pflügt von hinten durch das Feld, aktuell auf P29
 
Zuletzt bearbeitet:
Nee, die hat ja anscheinend jemand komplett weggesaugt und solang sie nicht reported werden, gibt es anscheinend keine Neuen.

Und wie passt die Aussage zur aktuellen Situation: nur 25 RxDock in Arbeit und trotzdem keine neuen?! *noahnung*

Solange sich das bei SiDock nicht ändert und LHC SixTrack anbietet, bleib ich bei LHC!

Gruß
Ritschie
 
Zurück
Oben Unten