Benutzer:Mxplm/Rechentipps

Auf dieser Seite möchte ich einige Tipps geben, wie man seine Hardware möglichst effizient für verteiltes Rechnen nutzen kann. Die genannten Konfigurationen beziehen sich auf BOINC und sind teilweise auf andere Clients übertragbar. Kritik, Fragen und Ideen bitte in den zugehörigen Forenthread posten).

Ziele

Zuerst müssen wir wissen, was wir eigentlich erreichen wollen. Dabei gibt es durchaus gegensätzliche Ziele, d.h. man muss einen Kompromiss finden.

Überblick

• Ergebnisse schnell abliefern
• Work Units korrekt berechnen
• Kommunikation mit dem Projektserver begrenzen
• CPU auslasten
• Ressourcen schonen (RAM, Festplattenzugriffe, Bandbreite)

Erläuterung

Für die Projektbetreiber kann es hilfreich sein, wenn die Ergebnisse einer Work Unit schnell zur Verfügung stehen (niedrige turnaround time, z.B. bei Rosetta@home der Fall). In jedem Fall sollten die Ergebnisse korrekt sein, damit die Aufgabe nicht erneut verschickt und berechnet werden muss. Zudem sollte der Projektserver nicht mit überflüssigen Anfragen befeuert werden, denn dies kostet den Projektbetreiber Bandbreite und damit oft bares Geld.

Wenn schon gerechnet wird, dann auch richtig. Der Prozessor sollte immer etwas zu tun haben, da sonst wertvolle Rechenzeit nicht genutzt wird. Andererseits soll der Computer benutzbar bleiben, man sollte vom verteilten Rechnen nichts merken. Das impliziert den schonenden Umgang mit Arbeitsspeicher, Festplatte und Bandbreite.

Wechsel zwischen Anwendungen vermeiden

Generell sollte die Einstellung "Wechsel zwischen Anwendungen alle X Minuten" so hoch wie möglich gesetzt werden. Dadurch wird eine WU komplett berechnet, ohne zwischdurch von anderen WUs unterbrochen zu werden.

Grund / Vorteile

• Durchschnittlich sind WUs schneller fertig.
• Falls die Einstellung "Lasse Anwedungen im Speicher, während sie pausiert sind" gesetzt ist, wird weniger Arbeitsspeicher belegt. Falls sie nicht gesetzt ist, muss seltener von der Festplatte gelesen werden, was sonst bei jedem Fortsetzen einer WU der Fall wäre.
• Bei WUs ohne Checkpoints ist die Einstellung besonders empfehlenswert, weil die Zeitspanne, in der die WU abgebrochen werden kann, auf ein Minimum reduziert wird.

Ausnahmen / Nachteile

• Es kann passieren, dass WUs im Arbeitsvorrat hinter sehr langen WUs verhungern, sie werden also nicht oder erst kurz vor Ablauf der Deadline bearbeitet. Falls man andere Projekte parallel zu einem Projekt mit überlangen WUs (z.B. Climate Prediction) laufen lässt, sollte man also einen kleineren Interval wählen.

Beispiel

Auf einem SingleCore werden 2 WUs von unterschiedlichen Projekten berechnet. Jede braucht 10 Stunden Rechenzeit und 100 MB RAM.

Variante 1: Wechsel zwischen Anwednungen alle 120 Minuten:

• Anwednungen bleiben im Speicher
  • Durchschnittlich belegter RAM: 190 MB
  • Plattenzugriffe um WU fortzusetzen: 0
• Anwendungen werden auf der Platte zwsichengespeichert
  • Durchschnittlich belegter RAM: 100 MB
  • Plattenzugriffe um WU fortzusetzen: 3
• 1. WU fertg nach: 18 Stunden
• 2. WU fertg nach: 20 Stunden

Variante 2: Wechsel zwischen Anwednungen alle 999999 Minuten:

• Durchschnittlich belegter RAM: 100 MB
• Plattenzugriffe um WU fortzusetzen: 0
• 1. WU ist nach 10 Stunden fertg
• 2. WU nach 20 Stunden

Variante 2 ist im Bezug auf die betrachteten Aspekte also das, was man in der Spieltheorie eine dominante Strategie nennt. Sie ist in jedem Aspekt genau so gut wie oder besser als Variante 1.

Arbeitsvorrat klein halten

Der Arbeitsvorrat lässt sich über die Einstellung "Verbinde etwa alle X Tage" und "Zusätzlicher Arbeitspuffer X Tage" im Reiter "Nutzung des Netzwerkes" einstellen. Hier sind zwei Ziele involviert, zwischen denen man einen Kompromiss finden muss. Einerseits soll die CPU immer ausgelastet sein, d.h. der Arbeitsvorrat sollte nicht leer laufen, andererseits sollen heruntergeladene WUs möglichst schnell berechnet werden. Höhere Priorität hat bei den meisten Projekten sicher die Auslastung der CPU.

Man sollte also einen Wert wählen, bei dem man sicher ist, dass der Rechner im Falle eines Abbruchs der Internetverbindung oder einer Downtime des Projektservers noch einige Zeit beschäftigt ist. Mehr sollte man aber nicht einstellen. So viel wie nötig, so wenig wie möglich.

Die Downtime eines Projektservers ist nur dann ein Problem, wenn man auf dem PC nur ein einziges Projekt laufen lässt. In diesem Fall kann ein Backup-Projekt die CPU nutzen, falls das Lieblingsprojekt mal länger offline ist.

Grund / Vorteile

• Bessere (kürzere) Turnaround time
• Festplattenplatz wird gespart

Ausnahmen / Nachteile

• Falls die Verbindung zum Internet bzw. zum Projekt längere Zeit unterbrochen ist, hat der Prozessor irgendwann keine Arbeit mehr.

Beispiel

Bei SIMAP stellen viele User einen großen Arbeitsvorrat ein, weil das Projekt nur einmal im Monat Arbeit herausgibt. Einige User bekommen nach wenigen Tagen keine neue Arbeit mehr, während andere durch den großen Arbeitsvorrat noch bis zu 10 Tage lang für SIMAP rechnen. Die Proteindatenbank von SIMAP ist so erst vollständig aktualisiert, wenn die letzten User ihren Arbeitsvorrat durchgearbeitet haben, d.h. 10 Tage nachdem die letzten WUs verschickt wurden.

Würde jeder User seinen Arbeitsvorrat klein halten, so könnte auch alle bis zum Ende mitrechnen. Insgesamt wäre die Datenbank früher auf dem neusten Stand. Anderen Forschern stünden die aktualisierten Daten somit schneller zur Verfügung, was ggf. wieder deren Arbeit beschleunigen würde.

Backup Projekt einrichten

Man kann ein Projekt als Backup-Projekt einrichten, indem man den Ressourcenanteil auf 0 setzt. Von diesem Projekt werden nur dann WUs bezogen, wenn kein anderes Projekt WUs anbietet. Von dieser Möglichkeit sollte man besonders dann gebrach machen, wenn ein PC normalerweise nur für ein einziges Projekt rechnet.

Weitere Informationen im Unofficial BOINC Wiki

Grund / Vorteile

• Die CPU wird sicherer mit Arbeit versorgt.
• Wenn möglich werden immernoch alle Ressourcen für die Lieblingsprojekte verwendet.

Ausnahmen / Nachteile

• Derzeit unterstützen noch nicht alle Projekte einen Ressource Share von 0.
• Nicht jedes Projekt ist als Backup geeignet.

Auf unnötige Handarbeit verzichten

Projekte an- und abmelden oder resetten, WUs abbrechen, Projekte manuell nach WUs fragen oder fertige WUs melden. All diese Aktivitäten sind bei einigen involvierten Crunchern häufiger zu beobachten. Allerdings beanspruchen sie die Bandbreite und die Datenbank der BOINC-Projektserver. Man sollte daher nach Möglichkeit nur eingreifen, wenn es wirklich notwendig ist. Das spart außerdem noch Zeit.

Grund / Vorteile

• Schonung der Bandbreite des Projektes
• Zeitersparnis

Ausnahmen / Nachteile

• -

Tuning in Maßen

Es gibt viele Wege seinen Rechner zu tunen. Mann kann z.B. seine CPU übertakten oder Optimierungen im Betriebssystem vornehmen. Dabei sollte man immer darauf achten, dass alle Anwednungen weiterhin fehlerfrei laufen.

Grund / Vorteile

• Mehr Leistung durch Tuning
• Keine verschwendete Rechenzeit wegen Berechnungsfehlern, etc.
• Keine verschwendete Lebenszeit wegen Fehlersuche und -korrektur.

Ausnahmen / Nachteile

• Es sollten nur Einstellungen gemacht werden, von denen man weiß, was sie tun und dass sie funktionieren werden.

Beispiel

Beim Übertakten der CPU muss oft die Spannung am Prozessor angepasst werden, damit bei den Berechnungen später keine Fehler entstehen.