MLC@Home

[pschoefer]

Das noch recht neue Projekt MLC@Home wird nun offiziell vom CORAL-Lab der University of Maryland unterstützt:

MLC@Home und CORAL
Spannende Neuigkeiten!

MLC@Home ist jetzt ein Projekt des Labors für Kognition, Robotik und Lernen (engl. Cognition, Robotics, and Learning, CORAL) an der University of Maryland in Baltimore County (UMBC).

Das hat einige Vorteile, nicht zuletzt Raum im Labor zum Betrieb von Hardware, neue Ideen für auszuführende Forschung und einen Platz zur Zusammenarbeit mit anderen Forschern, die womöglich nicht Teil der BOINC-Gemeinschaft sind. Vor allem ist die Unterstützung eines Forschungslabors einer Universität eine Rückversicherung für euch, unsere Freiwilligen, dass dieses Projekt sowohl wissenschaftlichen Nutzen als auch einen Zweck über einen einzelnen Forscher und dessen Ziele hinaus hat. In den nächsten Tagen werde ich unsere Webseite aktualisieren, um die neue Affiliation widerzuspiegeln.

Wie gewohnt könnt ihr weitere Einzelheiten zur aktuellen Forschung auf unserer Hauptseite finden oder uns unterstützen, indem ihr eure BOINC-Clients mit dieser Adresse anmeldet: https://www.mlcathome.org/mlcathome/
18.07.2020, 3:53:29 MEZ

Originaltext:

MLC@Home and CORAL
Exciting news!

MLC@Home is now a project of the The Cognition, Robotics, and Learning (CORAL) lab at the University of Maryland, Baltimore County (UMBC).

This brings many benefits, not the least of which is lab space to run equipment, new ideas for research to conduct, and a place to collaborate with other researchers who may not be members of the BOINC community. Most importantly, being backed by a university research lab provides some assurance to you, our volunteers, that this project has both academic merit and a purpose beyond a single researcher and their goals. Over the next few days I'll be updating our website to reflect the new affiliation.

As always, please see our main website, https://www.mlcathome.org for details on the current research, or join us by attaching your BOINC client to this URL: https://www.mlcathome.org/mlcathome/
18 Jul 2020, 2:53:29 UTC

[JayPi]

Schön und gut, wenn das Projekt gefördert wird. Bei mir läuft es dennoch nicht. Alles ist up to date und "fuse" habe ich installiert. ContOS7 hört anscheinend bei GLIBC_2.17 auf, vom Projekt verlangt wird GLIBC_2.18

[AxelS]

Was verlangt unter CentOS die Bibliothek GLIBC_2.18?

[JayPi]

Dies zeigt der Fehlerreport meiner letzten WU:

<stderr_txt>
../../projects/www.mlcathome.org_mlcathome/mlds_0.920_x86_64-pc-linux-gnu: /lib64/libc.so.6: version `GLIBC_2.18' not found (required by /tmp/.mount_mlds_03iDNEu/usr/bin/../lib/libstdc++.so.6)
</stderr_txt>

- - - Aktualisiert - - -

Zeige ich die installierte Version an:

Installed Packages
glibc.i686                        2.17-307.el7.1                       @base
glibc.x86_64                      2.17-307.el7.1                       @anaconda

[AxelS]

Das von Dir verwendete CentOS 7 ist veraltet, wie man in den Angaben Deines Rechners (799) sehen kann. Das Blöde dabei ist, die verwendete GLIBC_2.17 ist fester Bestandteil des Linux-Kernels von CentOS 7.

Dass dies so ist bin ich durch eine Recherche im Netz auf diesen Thread gestossen. Schade halt.

Vor einem Jahr habe ich auf einem meiner Rechner auch CentOS gehabt. Nach ca. 8 Wochen habe ich das BS gelöscht und bin zurück zu LinuxMint gewechselt.
Muß nach einem Jahr gestehen, meine Entscheidung war richtig und habe es bis jetzt nicht bereut.

Offensichtlich bringt LinuxMint alles mit, was man braucht. Jediglich MLC@Home musste ich im BOINC hinzufügen, alles andere lief sofort problemlos.

Wenn Du CentOS verwenden willst, dann versuche es mit der neuen Version (CentOS 8) welches im letztem Jahr, im September 2019 ge-released wurde.
Dieses beinhaltet glibc_2.28

Nur meine 5 cent

[JayPi]

Danke für Deinen Hinweis mit dem Artikel aus dem CentOS Forum! Die Version 8 hatte ich schon probiert, es gab aber noch zu viele Kinderkrankheiten. Vielleicht teste ich die Version 8 Ende August nochmal neu auf einem Rechner.

[JayPi]

Einen Rechner hatte ich bereits mit CentOS 8 laufen, dort ist die WU jetzt erfolgreich gestartet.

- - - Aktualisiert - - -

Unter Windows muss das Visual C++ Redistributable Package für Visual Studio 2015 in 64 bit installiert werden.

- - - Aktualisiert - - -

Jetzt habe ich auch gelesen, dass CentOS 7 ausdrücklich nicht supportet ist: siehe Artikel

- - - Aktualisiert - - -

Inzwischen erreichen mich die ersten Credits. Leider kann ich nur auf ein paar Rechnern das Projekt laufen lassen.

[KidDoesCrunch]

Hallo JayPi, herzlichen Willkommen bei MLC@HOME, die ersten 15.000 Credits bei Free-DC zu sehen.

[JayPi]

Da es wohl auch bei anderen Teilnehmern große Probleme mit kaputten Windows WUs gibt, ist der Entwickler an der Arbeit. Die Versionen der Applikation wechseln aktuell im Stundentakt.

[KidDoesCrunch]

Ja, ich habe jetzt schon ein paar Versionen durch :-) Wenn das noch lange so weitergeht wechsel ich wohl,

[KidDoesCrunch]

So 10.000.000 erreicht

[JayPi]

So 10.000.000 erreicht

Herzlichen Glückwunsch ... ich folge Dir demnächst ...

[KidDoesCrunch]

Folgen ist OK!

Dumme Aussage!

Für das Projekt ist es unerheblich wer wem folgt. Aus Projektsicht ist es lediglich erheblich was wir als Team leisten. FULL STOP. Sorry, manchmal geht es einfach mit mir durch :-(

[DerLetzteGermane]

MLC@Home unterstützt jetzt auch GPU

Ich habe gerade auch zwei durchgerechnet ohne Fehler.

- - - Aktualisiert - - -

Na ja besonders effizient läuft es noch nicht. Mit einer WU ist mein Cuda nur bei 70% und mit zwei bei 92%.
Dafür werden aber auch je 1 CPU Kern und 2Gb RAM pro WU benötigt.

- - - Aktualisiert - - -

<app_config>
    <app>
        <name>mlds-gpu</name>
        <gpu_versions>
            <gpu_usage>0.5</gpu_usage>
            <cpu_usage>0.49</cpu_usage>
        </gpu_versions>
    </app>
</app_config>

[No_Name]

Meine 1650 wird nur zu 20 % ausgelastet, hat noch jemand diese Probleme?

[pschoefer]

Das ist dann doch sehr niedrig, gerade für eine eher kleinere GPU. Hilft es evtl., einen CPU-Kern freizuhalten?

[lugu]

Meine GPU ist zu 0% ausgelastet, weil die 7 CPU-WUs zu viel RAM fressen...

[No_Name]

Das ist dann doch sehr niedrig, gerade für eine eher kleinere GPU. Hilft es evtl., einen CPU-Kern freizuhalten?

Ohne CPU WUs komme ich auf 15% Auslastung mit einer WU, bei zweien sind es 30 %. Mehr als 3 WUs bekomme ich nicht in den VRAM.
Treiber ist aktuell.

Edit: Mit 3 WUs bin ich schon bei 40 % Auslastung

[nexiagsi16v]

Wie sind die Laufzeiten deiner GPU WUs?

[DerLetzteGermane]

pro WU ca. 35min bei zwei gleichzeitig GPU und je ein CPU kern.

Dann habe ich auch eine Auslastung der GPU von 94%. Aber es werden auch zwei CPU kerne voll belastet und je 2GB RAM benötigt.

[KidDoesCrunch]

Meine 1080TI will absolut nicht mit MLC@HOME. Auslastung 0 %. Woran kann es liegen?

[JayPi]

Soviel ich weiss, müssen Linuxer noch fuse installieren

[taurec]

Soviel ich weiss, müssen Linuxer noch fuse installieren

Hm, also ich musste nichts zusätzlich installieren - Mint 19.3

[AxelS]

Warum soll ein Dateisystem im Userspace beim NVIDIA-Treiber Problem helfen? fuse ist ein Filesystem welches User ohne admin-Rechte mounten und nutzen dürfen...

Mir fällt aber was anderes auf: Die App für die GPU ist unter Linux ja dynamisch verlinkt. Bei meinen Linux-Kisten fehlen da noch einige librarys.
Meine GTX1660Ti wird aber zu 50% ausgelastet.

root@xxxxx:~# ldd ~boinc/projects/www.mlcathome.org_mlcathome/mlds-gpu_9.80_x86_64-pc-linux-gnu__cuda10200
        linux-vdso.so.1 (0x00007ffd3ab97000)
        libc10.so => not found
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fda0ab91000)
        libsz.so.2 => not found
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fda0ab75000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fda0ab6f000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fda0aa20000)
        libtorch_cpu.so => not found
        libtorch_cuda.so => not found
        libtorch.so => not found
        libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1 (0x00007fda0a9dc000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fda0a7ea000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fda0b394000)
root@xxxxx:~#

[taurec]

so ungefähr sieht das bei mir auch aus auf den ersten Blick:
linux-vdso.so.1 (0x00007ffef29d2000)
libc10.so => not found
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f63c4167000)
libsz.so.2 => not found
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f63c3f4a000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f63c3d46000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f63c39a8000)
libtorch_cpu.so => not found
libtorch_cuda.so => not found
libtorch.so => not found
libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1 (0x00007f63c3779000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f63c3388000)
/lib64/ld-linux-x86-64.so.2 (0x00007f63c4b47000)