Zum Inhalt springen

Berkeley Open Infrastructure for Network Computing

aus Wikipedia, der freien Enzyklopädie
Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 29. Juni 2006 um 16:47 Uhr durch 195.3.113.73 (Diskussion). Sie kann sich erheblich von der aktuellen Version unterscheiden.
BOINC

Der BOINC-Client für Linux
Der BOINC-Client für Linux
Basisdaten

Entwickler Universität Berkeley
Erscheinungsjahr 10. April 2002
Aktuelle Version 5.4.9
(12. Mai 2006)
Aktuelle Vorabversion 8.0.1[1]
(1. April 2024)
Betriebssystem Linux, Mac OS X, Solaris, Windows, diverse Unix-Derivate
Programmier­sprache C++
Kategorie Bereitstellung von Rechenleistung
Lizenz GPL/LGPL
deutschsprachig ja
boinc.berkeley.edu
BOINC-Logo
BOINC-Logo

Die Berkeley Open Infrastructure for Network Computing (BOINC) ist eine Softwareplattform für verteiltes Rechnen.

Die BOINC-Plattform wird an der Universität Berkeley entwickelt und ermöglicht es, die ungenutzte Rechenleistung von vielen tausend Computern über das Internet verfügbar zu machen.

Bei der Entwicklung wurden Erfahrungen des Distributed-Computing-Projekts SETI@home genutzt. Das Hauptziel der Plattform ist die Trennung der Projektverwaltung von den wissenschaftlichen Inhalten.

Anwender dieser Plattform installieren sich ein Clientprogramm und können damit ihre freie Rechenzeit auf mehrere Projekte verteilen. Dies stellt eine wichtige Verbesserung gegenüber an nur ein Projekt gebundenen Clients dar, da viele Distributed-Computing-Projekte nicht über genügend Arbeit verfügen, um eine große Benutzerbasis ausreichend zu versorgen. Wenn ihre Rechner leerlaufen, werden die teilweise sehr enthusiastischen Teilnehmer unzufrieden. SETI@home "classic" umging dieses Problem, indem manche Arbeitspakete bis zu zwölfmal zur Berechnung herausgegeben wurden, obwohl zur Sicherung von akkuraten wissenschaftlich verwertbaren Resultaten nur drei Ergebnisse notwendig wären. Mit einem an mehreren Projekten teilnehmenden BOINC-Client kann die zur Verfügung stehende Rechenleistung somit effektiver verwendet werden.

Seit dem 18. November 2003 steht BOINC unter der GNU General Public License. Das Ziel der Freigabe des Programmcodes ist eine noch breitere Unterstützung verschiedener Plattformen durch aktive Mithilfe der freien Softwaregemeinde und eine erhöhte Sicherheit.

Bestandteile

Teilnehmerseitig

  • Core-Client: Der Core-Client ist ein auf dem Teilnehmerrechner im Hintergrund laufendes Kommandozeilen-Programm. Er steuert und überwacht die wissenschaftlichen Anwendungen gemäß den Vorgaben des Teilnehmers, puffert Arbeitspakete und kommuniziert mit den Schedulern und Datenservern der Projekte. Der Core-Client kann theoretisch auf jedes Unix-artige Betriebssystem portiert werden, ist für sich allein genommen jedoch recht nutzlos, wenn für die jeweilige Plattform keine wissenschaftlichen Anwendungen zur Verfügung stehen.
  • BOINC Manager: Der BOINC Manager ist eine grafische Oberfläche zur Konfiguration und Überwachung des Core-Clients. Er basiert auf dem WxWidgets-Toolkit und ist damit auf allen Plattformen lauffähig, die von WxWidgets unterstützt werden.
  • Boinc-Commandline-Interface: das Programm boinc_cmd erlaubt es, den Core-Clienten über die Kommandozeile zu steuern, beispielsweise wenn keine grafische Oberfläche verfügbar ist (wie bei Servern).

Projektseitig

Das vom jeweiligen Projekt zur Verfügung gestellte Backend basiert auf einem Webserver, PHP als Skriptsprache und einer MySQL-Datenbank. Bei großen Projekten können die Backend-Dienste auf mehrere Server verteilt sein.

  • Scheduler: Der Scheduler ist ein CGI-Programm auf dem Webserver des Projekts. Er teilt den Teilnehmer-Clients ihre Arbeitspakete zu und nimmt nach getaner Arbeit eine kurze Meldung über Erfolg/Misserfolg entgegen. Über alle Aktivitäten führt er in der Datenbank Buch.
  • Datenserver: Ein einfacher HTTP-Server, von dem die Clients ihre vom Scheduler zugeteilten Arbeitspakete herunterladen und die Ergebnisdateien hochladen.
  • Validator: Der Validator (ein für jedes Projekt unterschiedliches Programm) prüft die von den Clients zurückgelieferten Ergebnisdateien auf Korrektheit. Meist geschieht dies dadurch, dass ein Arbeitspaket von mehreren Teilnehmern redundant bearbeitet wird. Der Validator vergleicht dann die Ergebnisse. Idealerweise sind sie identisch.
  • Assimilator: Ein projektspezifisches Programm. Nimmt validierte Ergebnisdateien und bereitet sie zur weitergehenden wissenschaftlichen Analyse auf. Dazu können die Ergebnisse beispielsweise in eine weitere Datenbank archiviert werden.
  • File-Deleter: Nachdem die Ergebnisse "assimiliert" wurden sind die Input- und Output-Dateien der Clients unnötiger Ballast für den Datenserver, die durch ihre Anzahl auch seine Performance beeinträchtigen können. Mit dem File-Deleter werden nicht mehr benötigte Dateien vom Server gelöscht.
  • Splitter: Projektspezifisches Programm. Sorgt für den Nachschub an Arbeitspaketen. Bei Projekten, die einen finiten Datenbestand analysieren, teilt er den Datenbestand in handliche Arbeitspakete auf. Bei anderen Projekten erzeugt der Splitter anhand bestimmter Parameter automatisch immer neue Arbeitspakete. Der Arbeitsvorrat ist bei solchen Projekten potenziell unendlich.
  • Transitioner: Der Transitioner überwacht den Fortschritt der Arbeitspakete entlang einer gedachten "Pipeline". So stößt er beispielsweise den Validator an, wenn er feststellt, dass zu einem Arbeitspaket genügend redundante Ergebnisse vorliegen, so dass mit der Validierung begonnen werden kann.

Funktionen

Das Verhalten des BOINC-Frameworks kann an die Bedürfnisse verschiedener Projekte angepasst werden. Zu den Funktionen, die nur von einigen Projekten genutzt werden, gehören:

  • Homogene Redundanz: Einige wissenschaftliche Anwendungen reagieren empfindlich auf nummerische Differenzen, die sich auf unterschiedlichen Teilnehmerrechnern ergeben können. Die Ursachen dafür können in den Betriebssystemen, den Prozessoren oder den verwendeten Compilern liegen. Kleine Unterschiede in der Rundung oder Fließkomma-Implementation können dabei zu völlig unterschiedlichen Ergebnissen führen. Im Falle von Predictor@home stellte man beispielsweise fest, dass Intel- und AMD-Prozessoren häufig unterschiedliche Proteinfaltungen errechneten. Keiner der Prozessoren hatte dabei "falsch" gerechnet, da man Proteinstrukturen ohnehin nur statistisch annähern kann, aber die Unterschiede waren signifikant genug, um den Validator aus dem Tritt zu bringen. LHC@home hat das Problem für sich durch eine neue plattformunabhängige Mathe-Bibliothek lösen können. BOINC-seitig besteht die Möglichkeit, ein Arbeitspaket jeweils nur identischen Plattformen zuzuteilen. Ein Arbeitspaket für "Windows/AMD" wird dann nur von Rechnern mit dieser Ausstattung bearbeitet.
  • Locality Scheduling: Bei einigen Projekten sind die Input-Dateien der Arbeitspakete sehr groß. Das belastet die Netzwerkanbindung des Projekts. Manche Projekte haben jedoch den Vorteil, dass für viele Arbeitspakete die gleichen Input-Dateien benötigt werden. Dann kann durch "Locality Scheduling" der Netzwerkverkehr reduziert werden. Ein Client bekommt in diesem Fall bevorzugt Arbeitspakete zugeteilt, zu denen er angibt, dass er die benötigten Input-Dateien bereits vorliegen hat. Diese Technik wird derzeit vor allem von Einstein@home verwendet.
  • Trickling: ClimatePrediction.net benutzt Arbeitspakete, deren Fertigstellung Wochen oder sogar Monate dauern kann. So lange möchten die Benutzer aber nicht auf Creditpunkte warten. Durch Trickling kann der Client den Scheduler über den Arbeitsfortschritt unterrichten, so dass bereits Creditpunkte vergeben werden können, während das Paket noch in Arbeit ist.
  • Datenarchivierung: Bis zu einer vom Teilnehmer festlegbaren Grenze können Projekte die Festplatte des Teilnehmerrechners zur Archivierung alter Input- oder Output-Daten verwenden. Das Projekt kommt an die Daten jedoch nicht ohne Kooperation des Teilnehmers heran. Wird derzeit nur von ClimatePrediction.net verwendet. Der Zeitaufwand zur Neuberechnung eines fertig gestellten Klimamodells wäre nämlich enorm. Die Ergebnisdateien von ca. 300 MB verbleiben daher auf dem Teilnehmerrechner. Wenn der Benutzer den Platz benötigt, kann er sie löschen oder vorher anderweitig sichern.

Projekte

Auf dem Rechner muss lediglich die BOINC-Software installiert werden. Nach der Registrierung bei einem oder mehreren der Projekte lädt BOINC sich selbständig die benötigte Projektsoftware herunter und beginnt den eigentlichen Rechenprozess. Inzwischen steht eine breite Auswahl an Projekten zur Verfügung oder wird gerade entwickelt:

  • Grid-Forschung:
    • Resource Measurement misst die verfügbaren Ressourcen von BOINC-Teilnehmern.
    • Crash Collection sammelt Core-Dumps von BOINC-Rechnern.
    • XtremLab ist ein geplantes französisches Projekt im Bereich Grid-Forschung mit ähnlichen Zielen wie Resource Measurement.
  • Sonstige:
    • BURP ist derzeit das einzige nicht-wissenschaftliche BOINC-Projekt. Es rendert 3D-Animationen.

Eine genauere Übersicht, welche Projekte aktuell laufen, finden Sie im BOINC-Wiki.

Projektseiten (englischsprachig)

Projektseiten (deutschsprachig)

Optimierte Software

Ein optimierter Core-Client bringt für sich genommen keine messbare Verbesserung der Rechenleistung, da er keine wissenschaftliche Arbeit bewältigt. Weil aber der "claimed credit" über eine Benchmarkfunktion im Core-Client kalibriert wird, können optimierte Clients unter Umständen mehr Credits bewilligt bekommen. Ob und wie die wissenschaftliche Software für spezielle Befehlssätze einzelner CPU-Familien optimiert ist, liegt in den Händen der Projekte (sofern die Software nicht Open Source ist). Die Bandbreite reicht dabei von einfacher CMOV-Unterstützung bei Predictor@home bis hin zu kompletten SSE- und AltiVec-Codepfaden bei Einstein@home.

Deutschsprachige Informationsquellen

  1. ↑ github.com. 1. April 2024.
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Berkeley_Open_Infrastructure_for_Network_Computing&oldid=18432748“