Leitfaden zum Bunkern

Aus Rechenkraft
Zur Navigation springen Zur Suche springen

Was ist Bunkern und wo liegt der Vorteil

Bei einem Wettkampt (Race) geht es in der Regel darum, innerhalb eines klar umrissenen Zeitfensters möglichst viele Credits für sich oder sein Team zu erwirtschaften. In den meisten Fällen ist es den Race-Veranstaltern egal, wann man die Wus heruntergeladen hat, was zählt ist der Zeitpunkt, wann die geleistete Rechenleistung gut geschrieben wird.

Bei einem Projekt mit Quorum 1 (jedes Result zählt sofort) kein Problem.

Bei einem Projekt mit Quorum 2, 3 oder gar noch mehr ist man aber darauf angewiesen, daß auch die anderen Cruncher (Wingman) , die die zugehörigen Gegenstücke crunchen, ihr Ergebnis ebenfalls im Zeitfenster des Race abliefern, sonst wird das mit den Credits nichts.

Erschwerend kommt jetzt hinzu, daß die Projekte jeder WU einen Zeitstempel (Deadline) mitgeben, bis wann sie abgeliefert werden muss. Wus, die nach Ablauf der Deadline abgeliefert werden, werden in der Regel nicht mehr mit Credits belohnt.

Jetzt wäre es also gut, wenn man irgendwie beeinflussen könnte, daß man selbst doch möglichst viele WUs bekommt, bei denen der Wingman diese ebenfalls im Zeitfenster des Race abliefert = optimalere Creditausbeute. Deswegen „bunkern“ viele Cruncher frühzeitig möglichst viele WUs, in der Hoffnung, daß viele andere ebenso verfahren und die gemeinsamen Ergebnisse dementsprechend zielsicher innerhalb des Race-Zeitfenster gutgeschrieben werden. Übrigens, je eher eine WU downgeloaded wurde, desto eher ist auch die Deadline, was wiederum die Chance erhöht, daß der / die Wingman die anderen Wus passend einliefert.

Weitere Vorteile von Bunkern sind die Unabhängigkeit davon, daß das Projekt vielleicht gerade mal keinen Nachschub hat und / oder der Projektserver aus irgend einem Grund länger nicht zu erreichen ist.

Bunkern steht nun als Begriff dafür, die lokale Queue von BOINC mit möglichst vielen WUs zu füllen.

Wann ist der richtige Zeitpunkt, einen Bunker zu füllen

Theoretisch so früh wie möglich, jedoch muß man darauf achten, daß die Deadlines der WUs nicht vor oder genau am Race-Start liegen. Deswegen kann es durchaus Sinn machen, den Bunker für das entsprechende Projekt erst zu einem späteren Zeitpunkt zu füllen

A) Einfaches Bunkern (für 1 Projekt) bei kooperativem Projektserver:

Will man nur für ein einzelnes Projekt bunkern und der Projektserver spielt problemlos mit, kann man folgendermaßen vorgehen:

  1. als Vorbereitung sollte man schon mal 1, 2 WUs des Projektes auf der Maschine rechnen lassen, um zu wissen, wie verhält sich die geschätzte Laufzeit zur tatsächlichen Laufzeit
  2. prüfen / ermitteln, wann ist der ideale Zeitpunkt zum Bunkern. (10 Tage vor RaceStart bei 4 Tagen Deadline der WUs macht bekanntlich wenig Sinn)
  3. alle nicht betroffenen Projekte auf "Anhalten („suspend“) oder zumindest "Keine neuen Aufgaben" („no new work“) stellen
  4. "Speichere mindestens xx Arbeitstage" („Store at least xx days of work“) und "Speichere zusätzlich für weiterer yy Arbeitstage" („Store up to additional yy days of work“) auf die gewünschte Reichweite einstellen, ggf. Korrekturfaktor aus a) berücksichtigen
  5. sicherstellen, daß das Ablaufdatum (die Deadline) zur gewünschten Reichweite paßt (ein 10 Tage Bunker bei 4 Tagen Deadline ist kontraproduktiv! )
  6. sicherstellen, daß der ResourceShare schlüssig ist / paßt, ggf. auf Projektserver, "Ihr Konto" („Your Account“), "Projekt-Einstellungen" („Settings for this project“), „ResourceShare (Ressourcenverteilung)“ anpassen, auf keinen Fall darf der 0 sein !
  7. den Client beim Projekt Arbeit anfordern lassen
  8. wenn der erste Schwung an Downloads erledigt ist, prüfen ob es ausreichend ist. Häufig rückt der Projektserver nicht sofort die volle Menge an WUs raus, die man haben möchte.
  9. ggf. nach Abwarten einer eventuellen Verzögerung (Hinweis im Event-Log: last contact too recent) ggf. erneut Arbeit anfordern lassen, bis der Bunker randvoll ist
  10. "Netzwerkzugriff pausieren" („suspend network activity“)

Nun sollte der Bunker gut gefüllt sein. Happy Crunching

B) Einfaches Bunkern (für 1 Projekt) bei Projektserver, der nur max nn-WUs / Core ausliefert

Die Details aus A) sollten jetzt bereits Routine sein, vielleicht ist der Bunker auch schon leicht bestückt, aber nicht ausreichend. Dann kann man den Projektserver überlisten:

  1. Alle Projekte, für die Arbeit auf dem Client vorhanden ist, anhalten (suspenden)
  2. BOINC komplett auf Pausieren (suspend) setzen
  3. Im Verzeichnis „BOINC_Data“ (Windows, Linux: Debian /etc/boinc-client/, ARCH /var/lib/boinc/) gibt es eine cc_config.xml, diese mit einem schlichten Editor öffnen, suche <NCPUS>-1</NCPUS> und ersetze die -1 durch eine Zahl deiner Wahl. Also z.Bsp. 12 für 12 Cores
  4. cc_config speichern
  5. Unter BOINC "Konfigurationsdateien einlesen" („read config files“) aufrufen, danach müßte BOINC die geänderte Anzahl der CPUs erkennen und einen neuen Benchmark durchführen
  6. setze "Netzwerkzugriff immer erlauben" („Network activity always“)
  7. ggf. das gewünschte Projekt "Fortsetzen" („Resume“) durchführen und "Neue Aufgaben zulassen" („allow new tasks“)
  8. Nachschub anfordern bis zum Limit, aber Achtung: mehr als nn-WUs mal Anzahl der Cores wird der Server nicht liefern
  9. Wenn der Projektserver auf einmal eine Meldung ausspuckt im Stil von „keine passende Applikation für das System“ versucht er, Dich abzuwimmeln und deinem Client eine 24-Stunden-Kontakt-Sperre zu verpassen
  10. Wenn alles gebunkert ist, was geht, BOINC unbedingt beenden
  11. Im Verzeichnis „BOINC_Data“ die cc_config.xml erneut editieren und <NCPUS>-xx</NCPUS> wieder auf -1 setzen und abspeichern
  12. BOINC erneut starten, "Netzwerkzugriff pausieren" („suspend network activity“) setzen und den Projekten erlauben wieder zu rechnen

Happy Crunching

C) Einfaches Bunkern bei mehr als einem Projekt

Die Details aus 1 und 2 sollten jetzt auch bereits Routine sein
Wenn ein Bunker bzgl. eines Projektes bereits gefüllt ist und man möchte ein 2.tes Projekt zusätzlich bunkern, muß man verhindern, daß die fertigen Results aus dem ersten Projekt zu früh hochgeladen werden. Hierzu verhindert man, daß der Client den Projektserver erreichen kann
Variante A) Über eine zentrale Firewall oder den Router
Hier wird zentral in der Firewall oder im Router die Zieladresse des gewünschten Servers blockiert
Variante B) Durch Editieren einer lokalen Datei names HOSTS
Die Datei HOSTS befindet sich:
*nix: /etc/hosts
OS X: /private/etc/hosts
Windows: C:\Windows\system32\drivers\etc\hosts
Zum Editieren bitte einen einfachen Editor verwenden
Auf der Seite https://krnlpnc.com/bunkerer/ gibt man die Projektdetails und das gewünschte IP-Protokoll (zur Zeit meist IPv4) an, dann kann man die benötigen Angaben per Cut & Paste in die lokale HOSTS-Datei eintragen
Die Datei HOSTS vor der Editierung:
# Copyright (c) 1993-2009 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
# 102.54.94.97 rhino.acme.com # source server
# 38.25.63.10 x.acme.com # x client host
# localhost name resolution is handled within DNS itself.
# 127.0.0.1 localhost
# ::1 localhost
HOSTS nach der Editierung
# Copyright (c) 1993-2009 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
# 102.54.94.97 rhino.acme.com # source server
# 38.25.63.10 x.acme.com # x client host
# localhost name resolution is handled within DNS itself.
# 127.0.0.1 localhost
# ::1 localhost
127.0.0.1 www.projektserver.com
Wichtig: Solange dieser Eintrag in der HOSTS-Datei enthalten ist, kann der gesamte PC den Server www.projektserver.com nicht erreichen; du kannst also in der Regel dann auch dort keine News oder Foreneinträge lesen / posten

4) Bunkern in Perfektion

Hierzu gibt es separate Threads im Forum
1) https://www.rechenkraft.net/forum/viewtopic.php?f=92&t=11662
2) https://www.rechenkraft.net/forum/viewtopic.php?f=92&t=15971