Nach oben

A

Account(< zurück)

Ein Account ist ein Konto eines Crunchers bei einem Projekt. Unter diesem Account werden die Hosts geführt, die ein User bei diesem Projekt verwendet.

Anonymous platform(< zurück)

Möglichkeit zum Einbinden von optimierten Anwendungen zu einem am Hosts angemeldeten Projekt. Siehe "Optimized applications".

Nach oben

B

Badge(< zurück)

Manche Projekte bieten verschiedene Anwendungen für unterschiedliche "Unter-Projekte". Meist kann man einstellen, von welchen dieser Unter-Projekte man Results geschickt bekommen möchte. Für das Erreichen eines bestimmten Creditwertes erhält man dann ein Badge, also sowas wie eine Medaille. Diese gibt es in unterschiedlichen Werten je nach erreichten Credits.

BOINC(< zurück)

Berkeley Open Infrastructure for Network Computing (BOINC) ist eine Entwicklung der University of California, Berkeley. Boinc ist aus dem ersten großen Verteiltes-Rechnen Projekt SETI@home I entstanden. SETI@home I (Search for ExtraTerestrial Intelligence) war eine Anwendung, die sowohl die Infrastruktur für verteiltes Rechnen bot als auch die wissenschaftliche Anwendung beinhaltete.
Der Infrastrukturteil wurde herausgelöst und so entstand Boinc, welches nun alle Funktionen für das Verteilen und Verwalten von Projektdaten und -programmen als auch für eine Teilnehmerverwaltung usw. bietet. Die ursprüngliche wissenschaftliche Anwendung wurde nach SETI@home II portiert und bedient sich nun der durch Boinc bereitgestellten Infrastruktur.

Nach oben

C

Claimed credit(< zurück)

Claimed credit ist der Credit, den ein Host nach Fertigberechnen eines Results fordert. Meist ermittelt der Host diesen Wert aus den Benchmarks und der für das Result benötigten CPU time.
Siehe auch Granted credit.

Client(< zurück)

Mit Client bezeichnet man den Softwareteil "Boinc" von Berkeley. Dieser Client stellt all die Funktionen zur Verfügung, die ein Projekt benötigt, um Arbeitspakete (Results) an User zu verteilen.

Boinc.exe ist der Core-Client. Das ist ein im Hintergrund laufendes Programm. Der Core-Client steuert die Projektprogramme entsprechend der Vorgaben durch den User und kommuniziert mit den Projektservern.

Boincmgr.exe, der Boinc-Manager, stellt eine Benutzeroberfläche zur Verfügung, mit der der Core-Client gesteuert wird.

Cloud Computing(< zurück)

Cloud Computing ist ein Begriff aus dem IT-Management. Es bezeichnet ein Konzept, nach dem Anwendungen und Daten nicht mehr auf dem lokalen PC oder Server liegen, sondern irgendwo im Netzwerk, also in der "Wolke". Der Zugriff erfolgt über ein Netzwerk, üblicherweise also das Internet oder das Intranet.

Credit(< zurück)

Die Basis für das Boinc Credit System ist:
ein Rechner mit 1000 doppeltgenauen MIPS gemäß dem Whetstone Benchmark (hauptsächlich Fließkommaberechnungen) und 1000 VAX MIPS gemäß dem Dhrystone Benchmark (hauptsächlich Ganzzahlberechnungen) soll für einen Tag Rechenzeit 100 Credits erhalten.
Diese Benchmarkwerte werden für jeden Host alle 5 Tage neu ermittelt und bei den Computer-Details unter "Measured floating point speed" bzw. "Measured integer speed" gespeichert.
Aus diesen Benchmarks und der benötigten Rechenzeit für ein Result werden die Claimed Credits ermittelt.

Diese Credits hießen ursprünglich Cobblestones nach einem SETI-Mitarbeiter Jeff Cobb.

Cross Project Identifier (CPID)(< zurück)

Eine CPID wird verwendet, um Accounts verschiedener Projekte dem gleichen User zuordnen zu können. Dafür hätte auch die E-Mail Addresse benutzt werden können, aber das hätte Spammern Tür und Tor geöffnet.

Boinc verwendet folgendes System:

• jedem Account wird beim Erzeugen des Accounts eine Zufallszeichenkette als interne CPID zugeordnet.
• der Scheduler schickt in einer Antwort an den Client diese Account CPID, die E-Mail Adresse und den Erzeugungszeitstempel. Das wird in der Datei client_state.xml gespeichert.
• wenn ein Boinc Client eine Anfrage an einen Scheduler schickt, durchsucht dieser die Accounts mit der der gleichen E-Mail Adresse, nimmt den Eintrag mit dem ältesten Erzeugungsdatum und schickt die dort gespeicherte CPID zurück.
• erhält der Scheduler eine andere CPID als die bei ihm gespeicherte, speichert er diese neue CPID.
• Benutzerdaten in den Statistikdateien enthalten einen Hash der E-Mail Adresse und der CPID. Diese externe CPID dient als eindeutige Zuordnung aller Accounts zu einer E-Mail Adresse.

Dieses System bietet somit eine Projekt-übergeordnete Identification basierend auf der E-Mail Adresse, ohne Informationen zu veröffentlichen, aus denen die E-Mail Adresse abgeleitet werden könnte.

Crunchers(< zurück)

Beschreibt eine Geisteshaltung (manche sagen auch Verrücktheit dazu), die sich in Besessenheit verwandeln kann. Cruncher müssen ihre Rechner immer auslasten und missbrauchen diese dazu, Zahlen zu verdrehen, zu rechnen, solange bis das Ergebnis passt. Der Proz schuftet also und der Cruncher streicht die Credits ein.

Echte Arbeitsteilung eben.

CUDA(< zurück)

Die Compute Unified Device Architecture, kurz CUDA genannt, ist eine von Nvidia entwickelte Technik zur Beschleunigung wissenschaftlicher und technischer Berechnungen. CUDA nutzt die enorme parallele Rechenleistung der zahlreichen Recheneinheiten des Grafikprozessors, welcher durch die CUDA-API quasi als Co-Prozessor zum Einsatz kommt.

Eine Übersicht über die CUDA-fähigen Grafikkarten findet ihr hier: CUDA enabled products. BOINC unterstützt CUDA ab der Version 6.4.5 und ein NVIDIA Treiber > 181.x wird auch noch gebraucht.

Die Liste der unterstützenden Projekte wächst ständig. Derzeit sind uns bekannt: Einstein@home, GPUGRID, SETI@Home, PicEvolvr, CollatzConjecture [wird fortgesetzt]. Schaut auch mal in unserem Forumsthread vorbei, vielleicht finden sich da noch mehr Informationen.

Nach oben

F

Fixed credits(< zurück)

Fixed credits bedeutet, dass der Wert für Granted credits nicht anhand der CPU-Zeit und der Benchmarks ermittelt wird, sondern ein vorher schon festgelegter Wert für ein Result vergeben wird.
Grund für die Einführung von Fixed credits war wohl die Manipulation der Benchmarks und damit auch der Credits.

Nach oben

G

GPU(< zurück)

GPU ist die Abkürzung für Graphics Processor Unit, das ist die Hauptrecheneinheit auf einer modernen Grafikkarte. Eine GPU kann die CPU entlasten, indem Rechenarbeit nicht nur von der CPU, sondern auch von der Grafikkarte erledigt wird. Hat bei uns also nix zu tun mit Glawnoje Polititscheskoje Uprawlenije, einen Geheimdienst der Sowjetunion.

Granted credit(< zurück)

Granted credit ist der vom Projekt für das Result vergebene Credit.

Nach oben

H

Host(< zurück)

Der Host ist der PC, auf dem Boinc und ein oder mehrere Projekte laufen.

Nach oben

I

Initial replication(< zurück)

Das ist die Anzahl Results, die für eine WU anfänglich verschickt wird.

Nach oben

O

Optimized applications(< zurück)

Manche Projekte geben den Source ihrer Anwedung heraus, die dann von Tüftlern verbessert werden. Möglichkeiten hierbei sind Umstellungen in der Anwendung selbst, die Benutzung von CPU-spezifischen Befehlssätzen wie z. B. die verschiedenen SSE-Versionen mit den entsprechenden Compiler-Schaltern oder auch das Miteinbeziehen einer GPU.
Bei manchen Projekten werden diese optimierten Anwendungsprogramme automatisch installiert, oft müssen diese aber auch getrennt heruntergeladen werden. Das sind in der Regel zumindest eine .EXE, die getunte Anwendung, und eine Datei app_info.xml, in der ein paar Informationen zu der neuen Anwendungen stehen. Dieser Mechanismus wird beim Boinc-Start erkannt und gemeldet als "anonymous platform".
Zur Installation der optimierten Anwendung wird Boinc gestoppt, die heruntergeladenen Dateien werden ins entsprechende Projektverzeichnis kopiert (z. B. nachD:\Boinc_Data\projects\setiathome.berkeley.edu) und danach Boinc wieder gestartet.

Nach oben

Q

Quorum(< zurück)

Das Quorum beschreibt die erforderliche Anzahl Results, deren Ergebnisse übereinstimmen müssen. Ein Quorum von zwei bedeutet, dass zwei gültige Results zurückgemeldet werden müssen, die im Ergebnis gleich sein müssen, damit die WU als erfolgreich berechnet gilt.

Nach oben

R

RAC(< zurück)

Recent average credits, kurz RAC, zeigt die Credits an, die ein User, ein Host oder auch ein Team durchschnittlich an einem Tag erarbeitet. Bei der Berechnung werden aktuell erhaltene Credits stärker gewichtet als ältere. Die Halbwertszeit ist eine Woche.
Einige Statisikseiten errechnen jeweils eigene RACs mit evtl. abweichenden Parametern.

Resource share(< zurück)

Auf den meisten Hosts laufen mehrere Projekte. Mit Hilfe des Parameters "Resource share" kann gesteuert werden, wieviel Zeit ein Projekt bekommt im Vergleich zu den anderen.

Result(< zurück)

Ein Result ist ein Arbeitspaket eines Projektes für einen Host. Häufig wird auch der Begriff WU dafür verwendet, was jedoch nicht immer korrekt ist. Siehe WU.

Nach oben

S

Scheduler(< zurück)

Der Scheduler ist ein Programm auf dem Projektserver, welches die Kommunikation mit den Clients steuert, also z. B. Results an den Client verschickt oder von diesem zurückgemeldet bekommt.

Nach oben

T

Team(< zurück)

Ein User kann ein Team gründen, dem dann andere User beitreten können. Alle Credits, die ab dem Beitritt zu einem Team erarbeitet werden, werden auch dem Teamkonto gutgeschrieben.
Zu einem Team können eine Beschreibung und auch eine URL angegeben werden.

Durch Einführung von Teams wird der Wettbewerbsgedanke vom User auf Teams erweitert.

Team founder(< zurück)

Der User, der ein Team gründet. Er kann die Teaminfos speichern und ist der einzige, der die E-Mail Adressen der Teammitglieder einsehen kann.
Die Eigenschaft "Team founder" kann auch auf ein anderes Teammitglied übertragen werden.

Trickle(< zurück)

Mit Hilfe von Trickles kann ein Client dem Server Informationen über den Fortschritt eines Results mitteilen. Dies ist inbesondere bei sehr lange laufenden Results wie z. B. von Climateprediction hilfreich, damit zum einen der Projektserver weiß, dass der Client das Result noch bearbeitet und wie weit er damit ist, zum anderen bekommt der User nach einer Trickle-Meldung auch entsprechende Credits gutgeschrieben und muss nicht warten, bis das Result komplett fertig ist.

Nach oben

V

Validator(< zurück)

Der Validator ist ein Prozess auf dem Projektserver. Er überprüft die zurückgemeldeten Results auf Gültigkeit, indem er z. B. die Results einer WU miteinander vergleicht.

Nach oben

W

Walltime(< zurück)

Die Walltime ist die Zeit, die während des Bearbeitens eines Results vergeht. Das entspricht bei einer 100% Auslastung eines Prozessorkerns auch der CPU time. Jedoch haben nicht alle Projekte diese Vollauslastung, insbesondere bei Projekten, die eine GPU verwenden, ist die Walltime größer als die CPU time.

Work Unit (WU)(< zurück)

Eine Work Unit besteht aus einem oder mehreren Results. Die Anzahl Results hängt ab vom benötigten Quorum und wird größer, wenn ein Result ungültig ist oder nicht innerhalb der Deadline zurückgemeldet wurde.