Zusammenfassung

  • Mit Client-Version 5.0 kamen 2004 Sammelserver hinzu: Sie konnten Ergebnisse annehmen, wenn der ursprüngliche Arbeitsserver unerreichbar war.
  • Der Betrieb blieb aufwendig. Im Juni 2009 berichtete Vijay Pande von ausgefallenen GPU-Servern und einer Umstellung bei knapper Personaldecke.

Wer seinen Rechner für die Wissenschaft arbeiten lässt, darf eine bescheidene Erwartung haben: Irgendwo muss er seine fertige Arbeit abgeben können. Das Gerät hat gerechnet, der Besitzer hat Zeit und Ressourcen bereitgestellt. Eine geschlossene Annahmestelle wirkt da wie ein ausgesprochen schlechter Dankesbrief.

Folding@home baute für diesen Fall einen zweiten Empfang. Die Architekturbeschreibung von 2009 datiert die Einführung der Sammelserver auf 2004, mit Version 5.0 des Clients. Der Gedanke war alltagstauglich: Ein Ergebnis sollte weiterkommen, auch wenn sein ursprünglicher Empfänger gerade ausfiel.

Abgabe mit Beleg

Das Projekt war laut eigener Chronik im Oktober 2000 im Labor von Vijay Pande an Stanford University gestartet. Freiwillige installierten Software, die Simulationsaufgaben bezog, bearbeitete und zurückschickte. Die Heimcomputer blieben unter der Kontrolle ihrer Besitzer.

Im gewöhnlichen Ablauf ging das fertige Ergebnis an den Arbeitsserver zurück, von dem die Aufgabe gekommen war. War dieser nicht erreichbar, sprang ein dafür vorgesehener Sammelserver ein. Er prüfte anhand der ausgegebenen Aufgaben, ob die Rücksendung passte, nahm sie an und verbuchte den Beitrag. Später leitete er sie an den wieder verfügbaren ursprünglichen Server weiter.

Der Client konnte inzwischen bei einem aktiven Arbeitsserver Nachschub holen. Das Projekt übernahm die Zwischenablage; der Spender musste mit seinem nächsten Beitrag nicht am kaputten Empfangsschalter warten.

Auch der reparierte Server hatte etwas davon. Weniger aufgestaute Rücksendungen bedeuteten weniger gleichzeitigen Ansturm nach seiner Rückkehr. Ein erfolgreicher Neustart, auf den sofort die nächste Überlastung folgt, ist eine Pointe, die vor allem Menschen außerhalb des Bereitschaftsdienstes schätzen.

Der unsichtbare Teil der Spende

Wie handfest dieser Betrieb war, zeigt Pandes Meldung vom 16. Juni 2009. Ein GPU-Server war schwer abgestürzt und fand seine Root-Partition nicht mehr. Zwei weitere waren unter hoher Last ausgefallen, ließen sich aber wieder starten. Gleichzeitig führte das Team neue Infrastruktur neben der alten ein und war personell stark beansprucht.

Besser funktionierende Sammelserver gehörten zu den erwarteten Vorteilen der Umstellung. Die Störungen bremsten deren Einführung. Der zusätzliche Empfang war also selbst ein Stück Infrastruktur, das Pflege verlangte.

Auf der anderen Seite saßen Menschen mit eigenen Grenzen. Die Architekturarbeit erwähnt Verbindungen mit mengenabhängigen Kosten, Modems und Einstellungen zur CPU-Nutzung. Sie beschreibt außerdem Punkte für einzelne Teilnehmer und Teams sowie freiwillige Helfer in den Foren. Wer etwas beitrug, sollte erkennen können, dass sein Beitrag angekommen war.

In der Bilanz von 2009 begrenzte bereits das Backend die Aufnahme weiterer Clients: Ergebnisse mussten empfangen, gespeichert und weiterverarbeitet werden. Die öffentliche Einladung zu mehr Rechenleistung erzeugte eine wachsende Verpflichtung hinter den Kulissen. Man kann Computer rund um die Welt einsammeln. Die Annahmestelle muss trotzdem geöffnet sein.