8. Pentathlon 2017 - LHC@home (Schwimmen)

Dann lass ich die nicht SSE2/PNI mal lieber links liegen.
 
Wenn du nicht händisch sortieren magst, versuch einfach mal der gen Anwendung das Executable Bit bzw. unter Windows die Ausführrechte zu entziehen, dann brechen die umgehend ab.
 
Hier sind eh gerade nur 5 Kerne am Rechnen, die haben eine überschaubare Anzahl WUs.
 
Bei mir freut sich die Telekom nicht das ich wieder Atlas rechne. ;D
Fein das der weg in die Schweiz so kurz ist und ich ne 50k Leitung hab.
Speicher reicht auch und Atlas ist auf meinen Kisten zuverlässig und berechenbar da sie nicht validiert werden müssen. *attacke**attacke**attacke*
 
Die anderen VM Apps sind doch auch 1ner Quorum!?
Von den Credits, so wie ich sehe, nehmen die sich nix.
 
ich baue hier nach und nach ein paar geladene LHC WUs ab aber an den 3 Minuten Restzeit der 8 Kern ATLAS WU rechnet er jetzt schon seit einer guten Stunde und ist dabei auf 2 Minuten Restzeit runter gekommen. *lol*
 
Das Wetter ist ja auch optimal zum Schwimmen. :D
 
und die 2 Minuten Restzeit meiner WU sind nach 2 Stunden auf 30 Sekunden runter! *party*
 
Hat irgendjemand ne funktionierende xml-Datei für LHC, damit der Client die WUs nur mit der 64-Bit PNI/SSE2 Anwendung berechnet? Wie es scheint hat mein Ryzen-System eine WU...
https://lhcathome.cern.ch/lhcathome/workunit.php?wuid=67259656
... mit der generischen 32-Bit-Anwendung berechnet und dafür 50.000 s gebraucht, wohingegen Ritschies Ryzen-System dieselbe WU mit der 64-Bit-SSE2-Anwendung gecruncht hat und damit schon nach nur 23.000 s fertig war :-/

Nachtrag:

Und warum die "win64" benannten Anwendungen in Wahrheit 32-Bit-Binaries sind, muss auch keiner verstehen, oder? *kopfkratz

win64_32.png
 
Zuletzt bearbeitet:
Die Creditvergabe ist schon ein arges Würfeln.
#1 SSE2 500s = 30cr.
#2 SSE2 10.000s = 90cr.
20fache Laufzeit und gerade mal 3x mehr Punkte.
Ich lass die PNI nun einfach mit drin, vielleicht bringen die unterm Strich sogar mehr.
 
Das ist doch, wie vielerorts, dieses Credit-New System.
 
Gibt es Erfahrungen um viel LHC unter Linux schneller berechnet wird als unter Windows?

Wenn das deutlich ist, würde ich nachdem Einstein durch ist, auf Linux booten und weiter LHC crunchen.
 
Hab heute nachmittag das versucht etwas zu analysieren. Konnte keinen signifikanten Unterschied zwischen Linux und Windows festgestellt.

--- Update ---

Gilt für Sixtracks.
 
Zuletzt bearbeitet:
Ich hatte bei den WUs, welche ich bei mir verglichen hatte, einen anderen Eindruck. Unter Windows im günstigsten Fall gleich, bei vergleichbar schnellen CPU´s und unter Linux schneller - bei teilweise schwächeren CPUs ... Sixtracks SSE2 und pni
 
Zuletzt bearbeitet:
Mal ne Frage, wie gut ist die Ausbeute bei den ATLAS WUs?
Mir blockiert eine davon seit 14 Stunden 8 Kerne.
 
Ich hatte bisher nur die Singelcore ATLAS WUs...
 
Eventuell bekomme ich morgen früh noch meinen alten FX-6350 (4.3GHz) für den LHC-Schlußspurt unter Linux an den Start. Hängt vom NT ab ... drückt die Daumen ;)
 
Ich habe gerade eine ATLAS abgebrochen die schon 21h lief und erst knapp über 7% Fortschritt hatte, keine Lust mehr auf Experimente. Ich gehe zurück auf Sixtrack, egal ob die nun das beste Creditverhältnis haben oder auch nicht. Sie laufen zuverlässig, RAMsparend, sind bunkerbar und geben auf dem R7 ~16000 Credits täglich.
 
Bei den Sims prüfe ich das Verhältnis der CPU/Laufzeit zueinander nach ~2 Stunden, weicht es stark ab, wird die WU gleich gekillt. Der RAM Bedarf schwankt stark, deswegen bin ich bei den Theory geblieben. Swapspeicher habe ich bei den HDD Systemen auf 0% gesetzt, RAM auf 99%. ATLAS WUs habe ich nie bekommen vom Server...
47,727.96 43,725.23 371.30 Theory Simulation v262.70 (vbox64) x86_64-pc-linux-gnu
33,504.77 33,196.42 243.37 SixTrack v451.07 (sse2) x86_64-pc-linux-gnu
 
Zuletzt bearbeitet:
Hab heute nachmittag das versucht etwas zu analysieren. Konnte keinen signifikanten Unterschied zwischen Linux und Windows festgestellt.

--- Update ---

Gilt für Sixtracks.

Ich habe ja selbst innerhalb von Linux bzw. auf dem gleichen PC extreme Unterschiede.
Das kann man unmöglich vorhersagen, zumindest nicht von den paar Tagen.
Nach 2 Wochen und ohne Pending wäre eine Statistik vielleicht aussagekräftig.
 
Hat irgendjemand ne funktionierende xml-Datei für LHC, damit der Client die WUs nur mit der 64-Bit PNI/SSE2 Anwendung berechnet? Wie es scheint hat mein Ryzen-System eine WU...
https://lhcathome.cern.ch/lhcathome/workunit.php?wuid=67259656
... mit der generischen 32-Bit-Anwendung berechnet und dafür 50.000 s gebraucht, wohingegen Ritschies Ryzen-System dieselbe WU mit der 64-Bit-SSE2-Anwendung gecruncht hat und damit schon nach nur 23.000 s fertig war :-/

Unter Linux sind die als lin64 deklarierten Anwendungen auch nur 32bit, was ein Jammer!

Ich habe eine PNI&SSE2 app_info.xml soeben einmal zusammenkopiert und getestet, allerdings für Linux:

Code:
<app_info>
<app>
    <name>sixtrack</name>
    <user_friendly_name>Sixtrack PNI&SSE2 only</user_friendly_name>
    <non_cpu_intensive>0</non_cpu_intensive>
</app>
<file>
    <name>sixtrack_lin64_4517_pni.linux</name>
    <status>1</status>
    <executable/>
</file>
<file>
    <name>sixtrack_lin64_4517_sse2.linux</name>
  <executable/>
</file>
<app_version>
    <app_name>sixtrack</app_name>
    <version_num>45107</version_num>
    <platform>x86_64-pc-linux-gnu</platform>
    <plan_class>pni</plan_class>
    <api_version>7.1.0</api_version>
    <file_ref>
        <file_name>sixtrack_lin64_4517_pni.linux</file_name>
        <main_program/>
    </file_ref>
</app_version>
<app_version>
    <app_name>sixtrack</app_name>
    <version_num>45107</version_num>
    <platform>x86_64-pc-linux-gnu</platform>
    <plan_class>sse2</plan_class>
    <api_version>7.1.0</api_version>
    <file_ref>
        <file_name>sixtrack_lin64_4517_sse2.linux</file_name>
        <main_program/>
    </file_ref>
</app_version>
</app_info>

Für Windows müsste die Datei dann folgendermaßen aussehen, basierend auf den zuvor hier genannten Angaben zu Dateinamen & plan_class:
Code:
<app_info>
<app>
    <name>sixtrack</name>
    <user_friendly_name>Sixtrack PNI&SSE2 only</user_friendly_name>
    <non_cpu_intensive>0</non_cpu_intensive>
</app>
<file>
    <name>sixtrack_win64_4517_pni.exe</name>
    <status>1</status>
    <executable/>
</file>
<file>
    <name>sixtrack_win64_4517_sse2.exe</name>
  <executable/>
</file>
<app_version>
    <app_name>sixtrack</app_name>
    <version_num>45107</version_num>
    <platform>windows_x86_64</platform>
    <plan_class>pni</plan_class>
    <api_version>7.1.0</api_version>
    <file_ref>
        <file_name>sixtrack_win64_4517_pni.exe</file_name>
        <main_program/>
    </file_ref>
</app_version>
<app_version>
    <app_name>sixtrack</app_name>
    <version_num>45107</version_num>
    <platform>windows_x86_64</platform>
    <plan_class>sse2</plan_class>
    <api_version>7.1.0</api_version>
    <file_ref>
        <file_name>sixtrack_win64_4517_sse2.exe</file_name>
        <main_program/>
    </file_ref>
</app_version>
</app_info>

Bitte nicht direkt auf Systeme mit fertigen WUs etc loslassen, nicht dass die noch abgebrochen werden. Vielleicht in einer Windows VM testen?

Beide Dateien lassen sich sicher noch kürzen, ich hatte das aus der client_state.xml herauskopiert, wird nicht alles benötigt werden...
 
Moin!

*motz*LHC schickt mir noch immer max 14 WU´s. Die beiden freigewordenen Kerne vom Einstein idlen munter vor sich hin. 100% CPU-Nutzung waren schon die ganze Zeit aktiv, habe jetzt noch die Grenzwerte für Computer in Benutzung etc. erhöht -> keine Änderung :[

Hat jemand noch nen Tip???
 
Zurück
Oben Unten