• Rosetta@home: Anpassungen bezüglich COVID und anderer großer Proteine

    Rosetta@home nimmt künftig nun auch große Proteine mit bis zu 2000 Aminosäuren (hier ein Beispiel mit 1273 Gliedern) ins Visier und veranschlagt dafür bis zu 4 GB RAM.

    Rosetta@home: Anpassungen bezüglich COVID und anderer großer Proteine

    Ich wollte versuchen, allen bewusst zu machen, dass das Projekt einige der größten Protein-WUs vorbereitet, die jemals auf R@h liefen. Diese werden pro Modell viel länger brauchen als kleinere Proteine. Das wird es sehr schwierig machen, die "geschätzte verbleibende Laufzeit" genau darzustellen. Es wird die Wahrscheinlichkeit erhöhen, dass Aufgaben länger laufen als eure WU-Laufzeitpräferenz vorgibt, insbesondere wenn ihr eine Laufzeitpräferenz habt, die weniger als die 8 Stunden Standardlaufzeit beträgt. Um dem Rechnung zu tragen, wird der Watchdog länger ruhen als früher und nur WUs beenden, die mehr als 10 CPU-Stunden länger als die Laufzeitpräferenz gelaufen sind.

    Diese lang laufenden Modelle werden zu einem hohen Grad an Laufzeitschwankungen zwischen den einzelnen Aufgaben führen. Es kann vorkommen, dass eine Aufgabe fast doppelt so viel Punkte erhält wie eine andere. Das liegt daran, dass sie zwei Modelle ausgeführt hat, anstatt eines. Die Gutschrift sollte im Allgemeinen proportional zur Menge der in die Aufgabe investierten CPU-Zeit sein.

    Diese hohe Variation in der Laufzeit wird eine Herausforderung für den BOINC-Manager bei der Entscheidung darstellen, wie viel Arbeit er anfordern sollte. Ihr könnt dem BOINC-Manager helfen, zu viel Arbeit zu vermeiden, wenn ihr euren Arbeitspuffer auf unter einen Tag begrenzt.

    Außerdem haben einige von euch kürzlich Arbeitseinheiten gemeldet, die vor ihrer Laufzeitpräferenz abgeschlossen wurden. Dies wird auch bei diesen lang laufenden Modellen häufiger vorkommen. Wenn ihr z.B. die standardmäßige Laufzeitpräferenz von 8 Stunden habt und das erste Modell 5 Stunden für die Fertigstellung benötigt, dann wird es nach 5 Stunden aufhören und zurück gemeldet, weil ein zweites Modell die Präferenz überschreiten würde. Das Projektteam zieht es vor, dass ihr die Laufzeitpräferenz nicht ändert, was derzeit zu 8 Stunden Laufzeit führt. Wenn diese hohen Laufzeitschwankungen euch jedoch Probleme bereiten, möchte ich darauf hinweisen, dass die Einstellung einer längeren Laufzeitpräferenz im Allgemeinen zu konsistenteren Bearbeitungszeiten führt. Beachtet einfach, dass Änderungen der Laufzeitpräferenz sowohl auf bestehende heruntergeladenen Arbeitseinheiten als auch auf neue Arbeitsanforderungen angewendet werden. Daher schlage ich immer vor, Änderungen nur dann vorzunehmen, wenn ihr einen kleinen Arbeitspuffer habt, und die Laufzeitpräferenz nur um kleine Schritte auf einmal zu ändern, damit der BOINC-Manager Zeit hat, die WUs mit den neuen Laufzeiten fertiggestellt zu sehen. Dies hilft ihm dabei, die Menge an Arbeit anzufordern, die euren Präferenzen entspricht.

    Die Arbeitseinheiten, auf denen sehr kurze Modelle liefen und die enden, wenn sie 1.000 Modelle (vor ihrer Laufzeitpräferenz) oder andere sehr runde Zahlen erreicht haben, wurden angepasst, um eine größere maximale Anzahl von Modellen zu ermöglichen. Dies wird helfen, eure vorgegebene Laufzeitpräferenz einzuhalten und die zusätzliche Zeit zu nutzen, um mehr Modelle zu berechnen. Dies wird dazu beitragen, dass die Laufzeiten dieser Art von Arbeitseinheiten konsistenter sind.


    Originaltext:
    Zitat Zitat von https://boinc.bakerlab.org/rosetta/forum_thread.php?id=13826#94811
    I wanted to try to help everyone be aware that the project is preparing some of the largest protein WUs even run on R@h. These will take much longer to run per model than smaller proteins. This is going to make "estimated runtime remaining" very difficult to show accurately. It will increase the likelihood of tasks running longer than your WU runtime preference, especially if you have a runtime preference that is less than the 8 hours default. To accommodate, the watchdog will be napping longer that he used to. Only ending WUs that have run more than 10 CPU hours longer than the runtime preference.

    These long-running models are going to result in a high degree of variation in runtime between tasks. You might see one task granted nearly twice as much credit as another. That because it ran two models rather than one. Credit should generally be proportional to the amount of CPU time invested in the task.

    This high variation in runtime is going to present a challenge for the BOINC Manager in deciding how much work it should be requesting. You can help the BOINC Manager avoid pulling down too much work if you adjust your preferences for how much work to store to be under a day.

    Also, several of you have recently reported work units that have completed before their runtime preference. This is going to become more common with these long-running models as well. As an example if you have the default 8 hour runtime preference and the first model takes 5 hours to complete, then 5 hours is where it will stop and report back because a second model would exceed the preference. The Project Team prefers you leave the runtime preference unset, which presently results in 8 hour runtimes. But if these high variations in runtimes are presenting problems for you, I should point out that setting a longer runtime preference will generally result in more consistent completion times. Just beware that runtime preference changes are applied to your existing downloaded work units as well as new work requests. So I always suggest making changes only when you have settings for a small work cache, and to only change the runtime preference a couple of notches at a time, so the BOINC Manager has time to see WUs complete with the new runtimes. This helps it request the amount of work that matches your preferences.

    The work units that were running very short models and ending when they reached 1,000 models (before their runtime preference), or other very round numbers, have been adjusted to allow a larger maximum number of models. This will help them fill out their runtime preference, using the additional time to compute more models. This will help runtimes of this type of work unit to be more consistent.
    Ursprünglich wurde dieser Artikel in diesem Thema veröffentlicht: News von der Rosetta-HP - Erstellt von: Major Original-Beitrag anzeigen
Single Sign On provided by vBSSO