World Community Grid - Wir haben ein Team hier!
- Ersteller indiana_74
- Erstellt am
Krümel
Grand Admiral Special
Habe wieder ordentlich MCM bekommen!
Also zugreifen Jungs und Mädels.
Also zugreifen Jungs und Mädels.
Sabroe SMC
Grand Admiral Special
November 21, 2025
We are testing required changes to the scheduler and feeder to resolve the corrupt/truncated "os_name" and "os_version" entries such as "W"/"W" for some hosts, as reported by users in the forums, and to resolve frequent "stuck" feeder states where "No tasks available for platform" is logically incorrect by hr_class, yet the tasks populating the feeder shared memory segment remain unassigned by the scheduler passes and manual intervention is required to get work flowing again.
Passes through uploaded results that have not been credited by the new system will begin next week, to backfill missing credits. We have been performing dry runs to establish correctness. As a precaution, we will be running the program in multiple passes starting with the oldest uploads, to the most recent.
Volunteers have reported that the API sometimes shows an invalid state for multiple results, where only one result is marked valid, which should be impossible. Preliminary investigation points to the new MCM1 assimilation procedure interacting with the transitioner. The new MCM1 assimilation procedure acts to validate and credit all in progress results for a workunit as soon as it has consumed any pair/quorum of files, whether original 0 and 1 results or resends 2 and up, that have passed validation. We will review this issue in full and report our findings, whether a bug in the assimilator, or poorly modeled interaction between assimilator transactions and the transitioner, which is where we expect to find an explanation.
Übersetzt mit Google Translation
21. November 2025
Wir testen die erforderlichen Änderungen am Scheduler und Feeder, um die fehlerhaften/abgeschnittenen Einträge „os_name“ und „os_version“ (z. B. „W“/„W“) für einige Hosts zu beheben, wie von Nutzern in den Foren gemeldet. Außerdem beheben wir häufige „hängengebliebene“ Feeder-Zustände, bei denen die Meldung „Keine Aufgaben für die Plattform verfügbar“ laut hr_class logisch falsch ist, die Aufgaben im Shared-Memory-Segment des Feeders aber von den Scheduler-Durchläufen nicht zugewiesen werden und ein manueller Eingriff erforderlich ist, um den Arbeitsablauf wieder in Gang zu bringen.
Ab nächster Woche werden die hochgeladenen Ergebnisse, die vom neuen System noch nicht gutgeschrieben wurden, verarbeitet, um die fehlenden Gutschriften nachzuholen. Wir haben Testläufe durchgeführt, um die Korrektheit sicherzustellen. Sicherheitshalber führen wir das Programm in mehreren Durchläufen aus, beginnend mit den ältesten Uploads bis hin zu den neuesten.
Freiwillige haben berichtet, dass die API manchmal für mehrere Ergebnisse einen ungültigen Status anzeigt, obwohl nur ein Ergebnis als gültig markiert ist. Dies sollte eigentlich nicht möglich sein. Erste Untersuchungen deuten darauf hin, dass das neue MCM1-Assimilationsverfahren mit dem Transition-Prozess interagiert. Das neue MCM1-Assimilationsverfahren validiert und schreibt alle laufenden Ergebnisse einer Arbeitseinheit gut, sobald es ein beliebiges Dateipaar bzw. Quorum verarbeitet hat – unabhängig davon, ob es sich um die ursprünglichen Ergebnisse 0 und 1 oder um erneut gesendete Ergebnisse ab 2 handelt –, die die Validierung bestanden haben. Wir werden dieses Problem eingehend untersuchen und unsere Ergebnisse berichten. Dabei werden wir klären, ob es sich um einen Fehler im Assimilationsverfahren oder um eine unzureichend modellierte Interaktion zwischen Assimilationsverfahren und Transition-Prozess handelt. Wir erwarten, dort eine Erklärung zu finden.
We are testing required changes to the scheduler and feeder to resolve the corrupt/truncated "os_name" and "os_version" entries such as "W"/"W" for some hosts, as reported by users in the forums, and to resolve frequent "stuck" feeder states where "No tasks available for platform" is logically incorrect by hr_class, yet the tasks populating the feeder shared memory segment remain unassigned by the scheduler passes and manual intervention is required to get work flowing again.
Passes through uploaded results that have not been credited by the new system will begin next week, to backfill missing credits. We have been performing dry runs to establish correctness. As a precaution, we will be running the program in multiple passes starting with the oldest uploads, to the most recent.
Volunteers have reported that the API sometimes shows an invalid state for multiple results, where only one result is marked valid, which should be impossible. Preliminary investigation points to the new MCM1 assimilation procedure interacting with the transitioner. The new MCM1 assimilation procedure acts to validate and credit all in progress results for a workunit as soon as it has consumed any pair/quorum of files, whether original 0 and 1 results or resends 2 and up, that have passed validation. We will review this issue in full and report our findings, whether a bug in the assimilator, or poorly modeled interaction between assimilator transactions and the transitioner, which is where we expect to find an explanation.
Übersetzt mit Google Translation
21. November 2025
Wir testen die erforderlichen Änderungen am Scheduler und Feeder, um die fehlerhaften/abgeschnittenen Einträge „os_name“ und „os_version“ (z. B. „W“/„W“) für einige Hosts zu beheben, wie von Nutzern in den Foren gemeldet. Außerdem beheben wir häufige „hängengebliebene“ Feeder-Zustände, bei denen die Meldung „Keine Aufgaben für die Plattform verfügbar“ laut hr_class logisch falsch ist, die Aufgaben im Shared-Memory-Segment des Feeders aber von den Scheduler-Durchläufen nicht zugewiesen werden und ein manueller Eingriff erforderlich ist, um den Arbeitsablauf wieder in Gang zu bringen.
Ab nächster Woche werden die hochgeladenen Ergebnisse, die vom neuen System noch nicht gutgeschrieben wurden, verarbeitet, um die fehlenden Gutschriften nachzuholen. Wir haben Testläufe durchgeführt, um die Korrektheit sicherzustellen. Sicherheitshalber führen wir das Programm in mehreren Durchläufen aus, beginnend mit den ältesten Uploads bis hin zu den neuesten.
Freiwillige haben berichtet, dass die API manchmal für mehrere Ergebnisse einen ungültigen Status anzeigt, obwohl nur ein Ergebnis als gültig markiert ist. Dies sollte eigentlich nicht möglich sein. Erste Untersuchungen deuten darauf hin, dass das neue MCM1-Assimilationsverfahren mit dem Transition-Prozess interagiert. Das neue MCM1-Assimilationsverfahren validiert und schreibt alle laufenden Ergebnisse einer Arbeitseinheit gut, sobald es ein beliebiges Dateipaar bzw. Quorum verarbeitet hat – unabhängig davon, ob es sich um die ursprünglichen Ergebnisse 0 und 1 oder um erneut gesendete Ergebnisse ab 2 handelt –, die die Validierung bestanden haben. Wir werden dieses Problem eingehend untersuchen und unsere Ergebnisse berichten. Dabei werden wir klären, ob es sich um einen Fehler im Assimilationsverfahren oder um eine unzureichend modellierte Interaktion zwischen Assimilationsverfahren und Transition-Prozess handelt. Wir erwarten, dort eine Erklärung zu finden.
Sabroe SMC
Grand Admiral Special
December 4, 2025
4. Dezember 2025
Das Problem mit der Meldung „Aufgaben, die anderen Plattformen zugewiesen wurden“ im BOINC-Feeder/Scheduler wurde behoben. Details zur Lösung und zu zukünftigen Maßnahmen, um dieses Problem künftig zu vermeiden, finden Sie weiter unten.
Die Bearbeitung des Validierungsrückstands für die während der Pause zurückgehaltenen Arbeitseinheiten sowie für Arbeitseinheiten, die durch unsere neue Validierungslogik nicht validiert wurden, hat begonnen. Wir werden diese Durchläufe in den kommenden Tagen intensivieren und nächste Woche über den Fortschritt und die voraussichtlichen Termine für die vollständige Nachbearbeitung aller dieser Fälle und die endgültige Validierung der laufenden Arbeiten berichten, da wir nun wissen, dass unser Skript zur Nachbearbeitung von Validierungen funktioniert.
Wir werden die BOINC-Dienste file_deleter und db_purge erst wieder starten, wenn wir jede Datei, die vor und nach der Pause hochgeladen wurde, validiert haben. Dies schließt auch das erneute Senden einiger „verwaister“ Dateien ein.
Wie wurde die Blockierung des Feeders/Schedulers aufgrund einer Diskrepanz der hr_class-Werte zwischen den Ergebnissen für dieselbe Arbeitseinheit umgangen? Die von uns gewählte Lösung für das Problem besteht darin, veraltete Feeder-Einträge zu löschen und deren hr_class (homogene Redundanz) auf 0 zurückzusetzen. Dadurch kann jeder Host/jede Plattform das Ergebnis herunterladen, falls es zu lange im Speicher verbleibt. Der Feeder kann über eine CLI-Option gestartet werden, wobei ein Zeitrahmen für die Belegung eines Slots durch ein Ergebnis festgelegt werden kann, bevor diese Vorgehensweise angewendet wird.
Was bewirkt das Zurücksetzen von hr_class=0 als Workaround? Die Zurücksetzung von hr_class=0 entspricht dem Wert, der neuen Workunit-Ergebnissen zugewiesen wird, die zum ersten Mal gesendet werden. Dies signalisiert dem Scheduler, dass jeder Host/jede Plattform dieses Ergebnis beanspruchen und berechnen kann (d. h., Ergebnisse _0 und _1 haben hr_class=0, erneute Sendungen verwenden die hr_class des Hosts, der bereits Ergebnisse gemeldet hat). Es entsteht ein gewisser Rechenaufwand, da eine zweite Validierungsstufe erforderlich ist, um sicherzustellen, dass die exakten Gensignaturen und ihre Werte zwischen den auf verschiedenen Plattformen berechneten Ergebnissen übereinstimmen. Dies gilt insbesondere für gelöschte Wiederholungssendungen, deren hr_class auf 0 zurückgesetzt wurde. Wir beabsichtigen, hr_class (homogene Redundanz) für MCM1 zukünftig vollständig zu deaktivieren und uns stattdessen direkt auf diese derzeit sekundäre Validierung zu stützen. Zudem werden wir die Differenz zwischen den exakten Werten und die Verifizierung äquivalenter Gensignaturen für die an verschiedene Plattformen gesendeten Ergebnisse protokollieren, um sicherzustellen, dass diese in der Regel innerhalb einer angemessenen Fehlertoleranz liegen.
Beeinträchtigt diese Umgehungslösung die Integrität der MCM1-Ergebnisse? Nein, sie führt jedoch zu neuen Sonderfällen, die berücksichtigt werden müssen. Der Wert kann innerhalb der oberen und unteren Grenze des möglichen Gleitkommafehlers zwischen Plattformen für dieselbe Arbeitseinheit variieren. Sicherzustellen, dass die Gleitkommaberechnungen nicht so stark voneinander abweichen, dass das Berechnungsergebnis ungültig wird, ist mit dem hr_class-Mechanismus deutlich einfacher. Da MCM1 jedoch sowohl eine Liste von Genen als auch einen Score erzeugt, besteht das einzige zusätzliche Validierungskriterium, das durch die Deaktivierung von hr_class entsteht, scheinbar darin, dass Ergebnisse mit einem Score knapp unter dem Schwellenwert auf diesem System ausgeschlossen und Ergebnisse mit einem Score knapp über dem Schwellenwert auf diesem System eingeschlossen werden – und zwar für spezifische Signaturen, die sehr nahe am konfigurierten Schwellenwert liegen. In diesen Fällen können wir die Vereinigung dieser zusätzlichen Ergebnisse, die knapp über oder unter dem Schwellenwert liegen, für alle Ergebnisse einer Arbeitseinheit verwenden, vorausgesetzt, die übrigen Ergebnisse oberhalb des Schwellenwerts sind gleichwertig.
Wozu braucht MCM1 dann überhaupt hr_class? In der Tat. Wir beabsichtigen, die oben genannten Fälle sowie alle weiteren Validierungsfehler zu verfolgen, bei denen wir unvorhergesehene Auswirkungen des erneuten Sendens an verschiedene Plattformen feststellen können. Wir versuchen, das System „hr_class deaktivieren, wenn der Feeder hängen bleibt“ für MAM1 zu testen. Dieses System verwendet eine numerische Optimierungsroutine zur Untersuchung des Signatursuchraums, die aufgrund von Gleitkommafehlern die tatsächlichen Signaturen verändern könnte und daher möglicherweise nicht optimal geeignet ist (die Berechnungen sind jedoch gültig, sodass eine angemessene Überlappung oder ein „Canary“- oder „Spike-in“-Validierungssystem als ausreichende Validierung gelten könnte). Wenn wir mit den Ergebnissen der Nachbearbeitung, die von verschiedenen Plattformen stammen, zufrieden sind, können wir die Funktion deaktivieren. Dies beschleunigt den Durchsatz und die Erkennung für MCM1 und möglicherweise auch für MAM1 und verschafft uns Zeit, dieses Problem für Anwendungen wie ARP1, auf die dieser Ansatz nicht zutrifft, dauerhaft zu lösen. Bei ARP1 müssen die Gleitkommaberechnungen byteweise äquivalent sein, andernfalls ist das Ergebnis ungültig. Sobald wir bestätigen können, dass neuere BOINC-Clients der Version 8.x+, die WSL auf Windows-Hosts zulassen, die einzige Ursache für diesen Fehler bei der hr_class-Verwirrung und möglicherweise auch für den Fehler bei der Abschneidung von os_name und os_version in "W"/"W" sind, können wir eine gezielte Korrektur anwenden.
- BOINC feeder/scheduler reporting "tasks committed to other platforms" is resolved - details are further down about the resolution and future plans to keep this issue from coming back.
- Validation Backlog has begun for workunits that were held over the break, and workunits that fell through our new validation logic unvalidated. We intend to ramp up these passes in the coming days, and will report on progress and project expected dates for fully backfilling all such cases and finally catching up validations to in flight work next week, now that we know our scripting works to backfill validations.
- We will not restart the file_deleter or db_purge BOINC services until we have validated every file we possess that was uploaded before/after the break, including sending resends for some cases of "orphans".
- What was the workaround for the feeder/scheduler blockage due to hr_class mismatch between results for the same workunit? The resolution to the issue that we chose for now, was to simply purge stale feeder entries effectively resetting their hr_class (homogenous redundancy) to 0 and allowing any host/platform to download the result if the result sits in memory for too long. The feeder can be started with a CLI option and specified time frame for occupancy of a result in a slot before it considers this course.
- What does resetting hr_class=0 as a workaround accomplish? The hr_class=0 reset matches the value assigned to fresh workunit results being sent out for the first time, essentially dictating to the scheduler that any host/platform may claim and compute this result (i.e., _0 and _1 results have hr_class=0, resends consult the hr_class of the host that reported results already). There is some computational overhead, as a second tier of validation is then required to validate the exact gene signatures and their scores are "the same" between these results computed on different platforms in the case of purged resends that had their hr_class reset to 0. We intend to disable hr_class (homogenous redundancy) completely for MCM1 at some point in the future, and instead rely directly on this currently secondary validation, and record of the delta between exact scores and verification of equivalent gene signatures found for these results sent to different platforms to ensure they are within a reasonable error bound/tolerance as a rule.
- Does this workaround affect the integrity of MCM1 results? No, but it does introduce a new edge cases to account for. The score can vary within the upper and lower bound of possible floating point error between platforms for the same workunit. Ensuring that the floating point calculations are not different enough to invalidate the computational result is a vastly easier problem when using the hr_class mechanism. However, because MCM1 produces a list of genes as well as a score, the only additional validation criteria we incur by disabling hr_class is ostensibly "score is just below the threshold on this system" exclusion, and "score is just above the threshold on this system" inclusion, for specific signatures very close to the configured threshold. In these cases, we can take the union of these additional results slightly above or below the threshold score, between all results for a workunit, provided the rest of the results above the threshold are equivalent.
- Why have hr_class at all for MCM1 then? Indeed. We intend to track the above cases and any other cases among validation failures where we can discern any unforseen effect of allowing resends to potentially go to different platforms, try this "disable hr_class if the feeder gets stuck" system for MAM1 which does have a numerical optimization routine to explore the signature search space that could change the actual signatures under test due to floating point error and so may not be a good candidate for this (and yet the calculations are valid, so any reasonable overlap or a "canary" or "spike-in" validation system might be considered sufficient validation...). If we are satisfied with the outcome of post-processing results that came from different platforms, we can disable it. This will accelerate throughput and discovery for MCM1 and possibly MAM1 while buying time to resolve this issue more permanently for applications such as ARP1 that this thinking does not apply to, where the floating point calculations must be byte-wise equivalent between results or the result is simply invalid. Once we can confirm that newer 8.x+ BOINC clients permitting WSL on Windows hosts is the only source of this hr_class confusion bug, and possibly the "W"/"W" os_name and os_version truncation bug, we can apply a targeted fix.
4. Dezember 2025
Das Problem mit der Meldung „Aufgaben, die anderen Plattformen zugewiesen wurden“ im BOINC-Feeder/Scheduler wurde behoben. Details zur Lösung und zu zukünftigen Maßnahmen, um dieses Problem künftig zu vermeiden, finden Sie weiter unten.
Die Bearbeitung des Validierungsrückstands für die während der Pause zurückgehaltenen Arbeitseinheiten sowie für Arbeitseinheiten, die durch unsere neue Validierungslogik nicht validiert wurden, hat begonnen. Wir werden diese Durchläufe in den kommenden Tagen intensivieren und nächste Woche über den Fortschritt und die voraussichtlichen Termine für die vollständige Nachbearbeitung aller dieser Fälle und die endgültige Validierung der laufenden Arbeiten berichten, da wir nun wissen, dass unser Skript zur Nachbearbeitung von Validierungen funktioniert.
Wir werden die BOINC-Dienste file_deleter und db_purge erst wieder starten, wenn wir jede Datei, die vor und nach der Pause hochgeladen wurde, validiert haben. Dies schließt auch das erneute Senden einiger „verwaister“ Dateien ein.
Wie wurde die Blockierung des Feeders/Schedulers aufgrund einer Diskrepanz der hr_class-Werte zwischen den Ergebnissen für dieselbe Arbeitseinheit umgangen? Die von uns gewählte Lösung für das Problem besteht darin, veraltete Feeder-Einträge zu löschen und deren hr_class (homogene Redundanz) auf 0 zurückzusetzen. Dadurch kann jeder Host/jede Plattform das Ergebnis herunterladen, falls es zu lange im Speicher verbleibt. Der Feeder kann über eine CLI-Option gestartet werden, wobei ein Zeitrahmen für die Belegung eines Slots durch ein Ergebnis festgelegt werden kann, bevor diese Vorgehensweise angewendet wird.
Was bewirkt das Zurücksetzen von hr_class=0 als Workaround? Die Zurücksetzung von hr_class=0 entspricht dem Wert, der neuen Workunit-Ergebnissen zugewiesen wird, die zum ersten Mal gesendet werden. Dies signalisiert dem Scheduler, dass jeder Host/jede Plattform dieses Ergebnis beanspruchen und berechnen kann (d. h., Ergebnisse _0 und _1 haben hr_class=0, erneute Sendungen verwenden die hr_class des Hosts, der bereits Ergebnisse gemeldet hat). Es entsteht ein gewisser Rechenaufwand, da eine zweite Validierungsstufe erforderlich ist, um sicherzustellen, dass die exakten Gensignaturen und ihre Werte zwischen den auf verschiedenen Plattformen berechneten Ergebnissen übereinstimmen. Dies gilt insbesondere für gelöschte Wiederholungssendungen, deren hr_class auf 0 zurückgesetzt wurde. Wir beabsichtigen, hr_class (homogene Redundanz) für MCM1 zukünftig vollständig zu deaktivieren und uns stattdessen direkt auf diese derzeit sekundäre Validierung zu stützen. Zudem werden wir die Differenz zwischen den exakten Werten und die Verifizierung äquivalenter Gensignaturen für die an verschiedene Plattformen gesendeten Ergebnisse protokollieren, um sicherzustellen, dass diese in der Regel innerhalb einer angemessenen Fehlertoleranz liegen.
Beeinträchtigt diese Umgehungslösung die Integrität der MCM1-Ergebnisse? Nein, sie führt jedoch zu neuen Sonderfällen, die berücksichtigt werden müssen. Der Wert kann innerhalb der oberen und unteren Grenze des möglichen Gleitkommafehlers zwischen Plattformen für dieselbe Arbeitseinheit variieren. Sicherzustellen, dass die Gleitkommaberechnungen nicht so stark voneinander abweichen, dass das Berechnungsergebnis ungültig wird, ist mit dem hr_class-Mechanismus deutlich einfacher. Da MCM1 jedoch sowohl eine Liste von Genen als auch einen Score erzeugt, besteht das einzige zusätzliche Validierungskriterium, das durch die Deaktivierung von hr_class entsteht, scheinbar darin, dass Ergebnisse mit einem Score knapp unter dem Schwellenwert auf diesem System ausgeschlossen und Ergebnisse mit einem Score knapp über dem Schwellenwert auf diesem System eingeschlossen werden – und zwar für spezifische Signaturen, die sehr nahe am konfigurierten Schwellenwert liegen. In diesen Fällen können wir die Vereinigung dieser zusätzlichen Ergebnisse, die knapp über oder unter dem Schwellenwert liegen, für alle Ergebnisse einer Arbeitseinheit verwenden, vorausgesetzt, die übrigen Ergebnisse oberhalb des Schwellenwerts sind gleichwertig.
Wozu braucht MCM1 dann überhaupt hr_class? In der Tat. Wir beabsichtigen, die oben genannten Fälle sowie alle weiteren Validierungsfehler zu verfolgen, bei denen wir unvorhergesehene Auswirkungen des erneuten Sendens an verschiedene Plattformen feststellen können. Wir versuchen, das System „hr_class deaktivieren, wenn der Feeder hängen bleibt“ für MAM1 zu testen. Dieses System verwendet eine numerische Optimierungsroutine zur Untersuchung des Signatursuchraums, die aufgrund von Gleitkommafehlern die tatsächlichen Signaturen verändern könnte und daher möglicherweise nicht optimal geeignet ist (die Berechnungen sind jedoch gültig, sodass eine angemessene Überlappung oder ein „Canary“- oder „Spike-in“-Validierungssystem als ausreichende Validierung gelten könnte). Wenn wir mit den Ergebnissen der Nachbearbeitung, die von verschiedenen Plattformen stammen, zufrieden sind, können wir die Funktion deaktivieren. Dies beschleunigt den Durchsatz und die Erkennung für MCM1 und möglicherweise auch für MAM1 und verschafft uns Zeit, dieses Problem für Anwendungen wie ARP1, auf die dieser Ansatz nicht zutrifft, dauerhaft zu lösen. Bei ARP1 müssen die Gleitkommaberechnungen byteweise äquivalent sein, andernfalls ist das Ergebnis ungültig. Sobald wir bestätigen können, dass neuere BOINC-Clients der Version 8.x+, die WSL auf Windows-Hosts zulassen, die einzige Ursache für diesen Fehler bei der hr_class-Verwirrung und möglicherweise auch für den Fehler bei der Abschneidung von os_name und os_version in "W"/"W" sind, können wir eine gezielte Korrektur anwenden.
MagicEye04
Grand Admiral Special
Was auch immer die da im Hintergrund machen - ich bekomme zuverlässig WUs und credits. 
Krümel
Grand Admiral Special
Jup, aber leider können die noch nicht exportiert werden
Wäre mal wieder interessant zu sehen, wo ich im Teamranking stehe.
Wäre mal wieder interessant zu sehen, wo ich im Teamranking stehe.
MagicEye04
Grand Admiral Special
Platz 28 oder so.
Team
What if you could support causes you care about while reading this post? Your device’s unused computing power can help scientists tackle some of the world’s biggest problems: from finding better #HIV and #cancer treatments to more efficient sources of renewable energy? I just joined World...
www.worldcommunitygrid.org
olsen_gg
Grand Admiral Special
Wow, da bin ich auch zu finden, sogar ohne zu scrollen.
Derzeit lauft WCG wider recht stabil, allerdings nur auf meinem alten i7 (gedrosselt auf 2GHz) mit Laufzeiten um die 3,5h. Da kommt nicht viel zusammen.
Derzeit lauft WCG wider recht stabil, allerdings nur auf meinem alten i7 (gedrosselt auf 2GHz) mit Laufzeiten um die 3,5h. Da kommt nicht viel zusammen.
Ähnliche Themen
Aktuelle Aktionen
Pentathlon 2025
Forumsthread
Webseite SG Pentathlon
Marathon 26.05 22:00 - 29.05. 21:59
Projekt: World Community Grid
Forumsthread
Forumsthread
Webseite SG Pentathlon
Marathon 26.05 22:00 - 29.05. 21:59
Projekt: World Community Grid
Forumsthread