Info 11th BOINC Pentathlon 2020

StefanR5R

Elite Member
Dec 10, 2016
5,459
7,718
136
pentathlon_rings.png
https://www.seti-germany.de/boinc_pentathlon/

boinc_pentathlon2.png

from 05 May 2020 00:00 UTC
to 19 May 2020 00:00 UTC
5 disciplines
1 winner

— [overall stats] — [TeAm AnandTech stats] —

boinc_pentathlon2unten.png

With ranks #5, #6, #2, #3, and #1 in the five contests, we won Silver in the overall ranking!
Thank you to all who supported the TeAm!
Big thanks to the organizers at SETI.Germany, as well as to the project administrators and scientists for their hard work.


Marathon at Rosetta@homestatsWe finished 5th.
Start: Tuesday May 5, 00:00 UTC (Monday May 4, 20:00 EDT / 17:00 PDT)​
End: Tuesday May 19, 00:00 UTC (Monday May 18, 20:00 EDT / 17:00 PDT)​
  • Project URL was changed from http to https on May 1. If you have still the old URL on your computers, you can keep using it. Switch over only at a time when you have no Rosetta tasks on the computer.
  • Task deadline is 3 days.
    • Hence, work at this contest can begin after Saturday May 2, 00:00 UTC (after Friday May 1, 20:00 EDT / 17:00 PDT) – i.e. download tasks, start computation but suspend network transfers.
    • After the stats table at the contest site was initialized, which should be shortly after May 5, 00:00 UTC, enable networking again to let the boinc client upload and report the results, as well as fetch more work.
  • Initial downloads of project files are huge; several hundreds MB at least. Subsequent downloads and uploads per task are moderate.
  • Each running task requires up to 1.5 GB 2.6 GB RAM (on average ≈0.9 GB) and about 1 GB disk space. (Tentative info, to be revised.) Suggested computing preferences:
    • On computers which are used for other work besides boinc, set "Memory – When computer is in use, use at most ... %" to something like 70.
    • On computers which do nothing but run boinc, set both "When computer is in use/ is not in use, use at most ... %" to something like 90.
    • Check the "Disk – Use no more than ... GB" setting. Make it large enough for the number of Rosetta tasks that you intend to run in parallel.
  • Task duration: By default 8 hours, irrespective of how quick or slow your computer is. (This can be reconfigured, see post #21.)
  • Quorum = 1: Validation of results happens on the server more or less quickly after your client reported results, depending on server load at the time. (This is in contrast to projects with quorum = 2, in which two contributor hosts are given the same task, and validation happens by comparison of the two results — hence can't happen before each of the two hosts returned their part. Credits are granted only after successful validation of course.)
  • Required workaround for Linux/x86-64 hosts for the previous Rosetta v4.15 application: The Linux/i686 variant was defective when run on a 64-bit host; it accomplished almost no real computation and therefore gave very poor credits. The following entry in /var/lib/boinc*/cc_config.xml prevents reception of i686 tasks on x86-64 hosts:
    <cc_config>
    <options>
    <!-- Rosetta@home workaround; set to 0 for other projects -->
    <no_alt_platform>1</no_alt_platform>​
    </options>
    </cc_config>
    Whether or not this workaround is still necessary with the current v4.20 application is yet to be verified.
  • Scheduler server: srv4.bakerlab.org
    (upload server and web server: boinc.bakerlab.org)

Javelin Throw at NumberFields@homestatsWe finished 6th.
Day 1: starts Tuesday May 5, 00:00 UTC (Monday May 4, 20:00 EDT / 17:00 PDT)​
Day 2: starts Sunday May 10, 00:00 UTC (Saturday May 9, 20:00 EDT / 17:00 PDT)​
Day 3: starts Thursday May 14, 00:00 UTC (Wednesday May 14, 20:00 EDT / 17:00 PDT)​
Day 4: starts Friday May 15, 00:00 UTC (Thursday May 15, 20:00 EDT / 17:00 PDT)​
Day 5: starts Monday May 18, 00:00 UTC (Sunday May 17, 20:00 EDT / 17:00 PDT)​
  • Task deadline is usually 10 days, sometimes 6½ days, rarely 3 days, depending on replication.
    In theory, this allows the entire period between announcement and start to be used for bunkering. But we don't know yet
    • what the exact announcement period for the other days will be (varies by up to 18 hours),
    • what the spacing between individual Javelin Throw days will be,
    • what other contests will overlap with Javelin Throw and its potential bunker periods.
  • NumberFields uses CreditNew, i.e. somewhat fuzzy credits per task.
  • Check out WUProp for an overview of task durations and other task properties.
  • If you have a GPU which is not saturated by the application, you can run two tasks at once on the same GPU by means the following app_config.xml file:
    <app_config>
    <app>
    <name>GetDecics</name>
    <gpu_versions>
    <gpu_usage>0.5</gpu_usage>
    <cpu_usage>0.01</cpu_usage>
    <!-- actual CPU usage is higher than that; reduce overall allowed CPU % accordingly -->
    </gpu_versions>​
    </app>​
    </app_config>
  • GDPR option available: You may choose whether or not your stats are exported to 3rd party sites. This does not affect team stats.
  • Quorum = 1
  • Limit on tasks in progress: 24 per active logical CPU, 200 per GPU.
  • Scheduler server: numberfields.asu.edu
    (same as upload server and web server)

City Run at Universe@Homestatsfinished: We achieved Silver!
Start: Thursday May 7, 00:00 UTC (Wednesday May 6, 20:00 EDT / 17:00 PDT)​
End: Tuesday May 12, 00:00 UTC (Monday May 11, 20:00 EDT / 17:00 PDT)​
  • Task deadline is 14 days.
  • Fixed credit per task: 1,333.33 for BHspin v2, 100.00 for ULX.
  • Two applications are currently active: "Universe BHspin v2" (WUProp), "Universe ULX" (WUProp). Both applications have CPU versions for x86-64 and ARM, but no GPU versions.
    • Mind the credit difference between these applications! You certainly want to enable only BHSpin v2 in Universe@Home preferences.
    • In addition, you may want to set "If no work for selected applications is available, accept work from other applications?" to "No". But then you need to monitor your clients a little more to make sure that you don't run out of tasks.
  • BHspin v2 performs better on Linux than on Windows with identical hardware.
  • GDPR option available: You may choose whether or not your stats are exported to 3rd party sites. This does not affect team stats.
  • Quorum = 2.
    This means that each workunit will consist of two tasks which are sent to different hosts. Both hosts need to return a result, and if they match, credit is given to both hosts. If they don't match, another task of the workunit is sent to a third host, and so on. And now remember that task deadline is 14 days. The upshot: It may take a good while until you get credit for a returned result.
  • Limit on tasks in progress: 24 per active logical CPU.
  • Scheduler server: debian1.universeathome.pl
    Upload server and web server: universeathome.pl

Cross Country at Amicable Numbersstatsfinished: We got Bronze!
Start: Tuesday May 12, 00:00 UTC (Monday May 11, 20:00 EDT / 17:00 PDT)​
End: Sunday May 17, 00:00 UTC (Saturday May 16, 20:00 EDT / 17:00 PDT)​
  • Task deadline is 5 days.
  • Fixed credit per task: 6,836.19
  • Application versions available for AMD GPUs, NVidia GPUs, and multithreaded CPUs.
  • We definitely need our CPUs in the other contests. There disable CPU work in the Amicable Numbers preferences and allow only work for AMD GPUs and/or NVIDIA GPUs.
  • Requirements of the current GPU application:
    • 8 GB RAM per task. Yes, that much. :-(
    • Any AMD (HD 5xxx or newer) or NVIDIA (GTX 4xx or newer) GPU with OpenCL support and at least 2 GB of video memory.
    • If you run an AMD card on Windows, make sure you use driver version 14.12 or newer, otherwise it may fail at startup because of OpenCL code compilation error.
  • Check the GPU utilization during run time (after the first half minute or minute setup period, in which only the CPU is busy but the GPU still idle). If you get markedly less than 100 % shader utilization (GPU core utilization), try with an increased "kernel size" at the Amicable Numbers preferences. Maxed-out utilization will also cause screen lag though, if the GPU drives your desktop.
  • GPU task run times may range from a minute to hours on one and the same GPU.
  • Quorum = 2.
  • Limit on tasks in progress: 20 per GPU.
  • Scheduler server: sech.me
    (same as upload server and web server)

Sprint at Ibercivis BOINCstatsWe won Gold!
Start: Saturday May 16, 00:00 UTC (Friday May 15, 20:00 EDT / 17:00 PDT)​
End: Tuesday May 19, 00:00 UTC (Monday May 18, 20:00 EDT / 17:00 PDT)​
  • Task deadline is 7 days.
  • Applications:
    • Main application: "Covid-Phym, Fight against SARS-CoV-2 replication"
      CPU-only application versions for Windows x86, Linux x86-64, Mac x86 available.
    • Beta test application: "Autodock Vina" – should perform better on Linux than on Windows, according to performance of Vina-based subprojects at World Community Grid
      CPU-only application versions for Windows x86, Linux x86-64
      There are no tasks available for this application currently.
    • The core of Covid-Phym is Autodock Vina. Hence the same performance consideration as for the beta test application should be applicable. (Linux > Windows.)
  • Task duration is highly variable:
    • Durations are mostly at the order of 10 hours, perhaps more than half a day on slower CPUs.
    • Task durations at the order of minutes and at the order of an entire day have been observed on one and the same host. Short tasks get low credit, long tasks get high credit.
    • The estimated time remaining is completely false before a task runs. It corrects itself while the task is running and making progress.
    • Workunit batches as of circa May 14 12:00 UTC seem to have task durations at the order of a few hours. — Nope, the huge variability is still there.
  • RAM requirement is negligible.
  • The application does not support checkpoints. — Resolved by application update on May 14.
    • To avoid progress loss during suspension of computing, go to boincmgr's advanced view, "Options" -> "Computing preferences..." -> "Disk and memory" tab, and switch on "✓ Leave non-GPU tasks in memory while suspended".
    • In addition, try not to shutdown or reboot your computer. Instead, suspend/ hibernate the computer, if possible.
  • Quorum = 1.
    • Initital replication = 2. That is, a Workunit is replicated into two tasks at first which are both sent to different hosts.
    • The first host to return a correct result gets credit.
    • The second host to return a correct result gets credit too, usually.
    • However, it has repeatedly happened in the past that the server canceled the second task after a result from the first task was validated.
    • (To be revisited.)
  • Limit on tasks in progress: 5 per active logical CPU, but no more than 320 per host (that is, no more than 64 logical CPUs are considered for the quota) — There was only a very brief period in time on May 14 with a limit on tasks in progress. The limit was removed again.
  • Scheduler server: boinc.ibercivis.es (same as web server)
    Upload server: subida.ibercivis.es


Looks like too much or too complicated to digest? Ignore the details. Simply run Rosetta@home for TeAm AnandTech for the duration of the Pentathlon. :-)
Thanks!


Contest calendar:
Code:
                             Tu We Th Fr Sa Su Mo Tu We Th Fr Sa Su Mo
                    02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18
     Rosetta@home   __ __ __ ▄▄ ▄▄ ▄▄ ▄▄ ▄▄ ▄▄ ▄▄ ▄▄ ▄▄ ▄▄ ▄▄ ▄▄ ▄▄ ▄▄   14 days Marathon
    Universe@home    _ __ __ __ __ ▄▄ ▄▄ ▄▄ ▄▄ ▄▄                         5 days City Run
 Amicable Numbers                         _ __ __ ▄▄ ▄▄ ▄▄ ▄▄ ▄▄          5 days Cross Country
  Ibercivis BOINC                                     _ __ __ ▄▄ ▄▄ ▄▄    3 days Sprint
NumberFields@home   __ __ __ ▄▄                                           1 day  Javelin Throw
                                   __ __ __ ▄▄                            1 day
                                               __ __ __ ▄▄                1 day
                                                  __ __ __ ▄▄             1 day
                                                           __ __ __ ▄▄    1 day
                    02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18
                             Tu We Th Fr Sa Su Mo Tu We Th Fr Sa Su Mo



Previous info:
On April 11 pschoefer said:
Dear Pentathletes,

5 May 2020, the starting day of the eleventh BOINC Pentathlon, is only a few weeks away. Even in difficult times, SETI.Germany invites all Volunteer Computing enthusiast teams to participate in the five disciplines over two weeks and to gather in front of their computers - everyone in front of their own computer, of course. Maybe some of us will go through a different illness than the Pentathlon fever or spend much of their time keeping important businesses such as healthcare or food supply running. Let's not forget the former and thank the latter by crunching a work unit for all of them!

While the process and rules remain largely unchanged from last year, a maximum of flexibility is needed for choosing the projects, as maybe one project needs the computing power more urgently than others or a project may be unavailable on short notice. To make the Pentathlon nevertheless as exciting and trouble-free as possible, not only the Marathon project, but all five projects are chosen by a small group of the organizers this year.

The teams can now sign up until 2 May using this form. We're looking forward to welcoming you again, because:

It will be exciting again at the BOINC Pentathlon!


────────

See Tony's intro below.

────────​

This year's changes to rules:
  1. All five projects are chosen by the organizers.
  2. More than one GPU project is possible.
In other words, no team votes for projects this time.
All we have to do is to have a member of ours register the TeAm. — update: done, we are registered.

────────​

Past Pentathlons:
forum threads2019201820172016201520142013201220112010
stats2019201820172016201520142013201220112010
# of teams29323433272832312729
our rank5ᵗʰ7ᵗʰ10ᵗʰ13ᵗʰ18ᵗʰ16ᵗʰ15ᵗʰ

____________
April 30, 00:00 UTC: Marathon project announced
May 2, 00:00 UTC: Javelin Throw project, and Javelin Throw day 1 announced
May 2, 18:00 UTC: City Run announced
May 7, 00:00 UTC: Javelin Throw day 2 announced
May 9, 06:00 UTC: Cross Country announced
May 11, 00:00 UTC: Javelin Throw day 3 announced
May 12, 00:00 UTC: Javelin Throw day 4 announced
May 12, 18:00 UTC: no announcement of the Sprint yet, it will therefore start on May 16, 00:00 UTC
May 13, 18:00 UTC Sprint announced
May 13, 18:00 UTC: no announcement of Javelin Throw day 5 yet, it will therefore be either May 17 or May 18
May 15, 00:00 UTC: Javelin Throw Day 5 announced
 
Last edited:

Assimilator1

Elite Member
Nov 4, 1999
24,120
507
126
Am I right in saying we won't know the chosen projects until the end of the month?
 
Last edited:

TennesseeTony

Elite Member
Aug 2, 2003
4,204
3,631
136
www.google.com
We won't know the projects until just before they START (except for the first event, I think), and it is a staggered start, with much overlap, so as to test the teams' planning skill/strategy.


*****************************


If anyone is reading this who has only recently joined us for the Folding event, this is the Olympics of Distributed Computing. It consists of 5 BOINC projects, run at different times, with some overlap, plus the Marathon project is always in progress.​
The TeAm has grown from placing in the mid-teens year after year, to being 7th or higher in the last few years. The raw power of the top teams is just amazing, so we could certainly use your help! :) As you likely know by now, Folding@Home is only one of the projects you can do. If your interest is medical research, there are many BOINC projects devoted to that, perhaps one or more will be chosen for this Pentathlon.​
 
Last edited:
  • Like
Reactions: Assimilator1

StefanR5R

Elite Member
Dec 10, 2016
5,459
7,718
136
The Marathon project will be announced on April 30, 00:00 UTC, as the first of the 5 projects.
(That's Wednesday, April 29, 20:00 EDT = 17:00 PDT.)

The second project will likely be announced very soon after this.
 
Last edited:

Ken g6

Programming Moderator, Elite Member
Moderator
Dec 11, 1999
16,220
3,802
75
Alright, I registered us for the BOINC Pentathlon. It says we have to be approved by an administrator before we show up as registered.
 

Fardringle

Diamond Member
Oct 23, 2000
9,184
753
126
I wish I could say I'd have my new Ryzen 3900X system up and running for the first project in the Pentathlon, but that's not likely. I'll put what few resources I have into the tasks I can run,and add the Ryzen beast whenever the parts are delivered and assembled.

Nothing compared to what some people have available, but it will certainly be a nice boost for me. If my calculations are right, it will almost double my current total CPU production. :)
 
Last edited:

StefanR5R

Elite Member
Dec 10, 2016
5,459
7,718
136
From the shoutbox at the Pentathlon site: Should the organizers run out of options, they may re-run a project of Pentathlon 2019. (In previous Pentathlons, projects of the prior year were not eligible.)
 
  • Like
Reactions: TennesseeTony

StefanR5R

Elite Member
Dec 10, 2016
5,459
7,718
136
Here is a refresher on the rules and schedule:

There will be five contests at different BOINC based projects. (The contests are called Marathon, Sprint, City Run, Cross Country, Javelin Throw). In each contest, the teams get points based on their rank in the contest. In the end, all "Pentathlon points" together determine the team ranks of the Pentathlon as a whole. (I.e. not the sum of BOINC credits; they are not comparable between different projects.)

Marathon
  • Start – end/ duration: 05 May 2020 00:00 UTC19 May 2020 00:00 UTC/ 14 days
  • Project announcement: April 30, 00:00 UTC (5 days before the start)
  • Note, "start" and "end" denote the period during which BOINC credits which the project awards to the team count towards the Pentathlon result. I.e. it doesn't directly matter when tasks are downloaded and when results are uploaded and reported; what matters is when results are validated at the project server. The same is true for the other projects.
  • This will most likely be a CPU project.
Sprint
  • Start – end/ duration: TBA 00:00 UTC – TBA 00:00 UTC / 3 days
  • Project announcement: not known yet (circa 3 days before the start)
  • This will most certainly be a project with quorum = 1, i.e. where we don't need wingmen to send a second result for validation.
  • The announcement will happen randomly at either 00:00 or 06:00 or 12:00 or 18:00 UTC, and the same will be true with the other three projects below.
  • May be a CPU project or a GPU project.
City Run, Cross Country
  • Duration: 5 days each, but different start/ end dates
  • Project announcements: One of these will be announced circa 5 days before its start, the other circa 3 days before its start.
  • May be CPU projects or GPU projects. In the past, Pentathlons had at most one GPU project in total, this year it may be two.
Javelin Throw
  • Duration: 5x 1 day. Unlike the other disciplines, these days are not consecutive.
  • Project announcement: circa 3 days before the 1st contest day
  • The date of each contest day will be announced circa 3 days in advance of the contest day.
  • In the other disciplines, the total credits achieved within all contest days of the discipline count towards the team result. Not so in Javelin Throw: Here, each day counts for itself, and the final result of the team will be its 3rd best = 3rd worst day.
  • Therefore the least resource-intensive approach is to have 3 almost equally good throws, and 2 bad throws during which the team puts its computers to a different discipline. (This can only be achieved if the team coordinates internally who is doing what.) At the same time, teams will watch each other how "far" everyone is throwing, and will attempt to make their best 3 throws just a little bit further than the next competing teams. Therefore, 4 good throws may bring tactical advantages, although being costly.
  • I guess the project will be a CPU project, and have a quorum of 1, although that's not certain.
 
Last edited:

TennesseeTony

Elite Member
Aug 2, 2003
4,204
3,631
136
www.google.com
@Markfw , if you could switch your WCG machines (ALL your machines) to Rosetta for the next 3 weeks, it would be greatly appreciated!

As suggested by Ken g6, go to the homepage and set your preferrences to run each task for 24 hours, then download at least 5 days worth of tasks, and turn off networking so you can start building your bunker.
 

Markfw

Moderator Emeritus, Elite Member
May 16, 2002
25,483
14,434
136
@Markfw , if you could switch your WCG machines (ALL your machines) to Rosetta for the next 3 weeks, it would be greatly appreciated!

As suggested by Ken g6, go to the homepage and set your preferrences to run each task for 24 hours, then download at least 5 days worth of tasks, and turn off networking so you can start building your bunker.
Well, I guess I could switch a few over.
 

Endgame124

Senior member
Feb 11, 2008
954
669
136
I’ve already got almost everything on Rosetta, but I'll stop folding with my 10 CPUs on my 2700X and move them over to Rosetta. I'm toyed with setting up the Raspberry Pi 2, but I decided against it as I would only be able to get, at most, 2 jobs running on it and it would probably take all day to process. If we lose by 10 points, you can blame me for not moving the Pi 2 :D
 

StefanR5R

Elite Member
Dec 10, 2016
5,459
7,718
136
Marathon at Rosetta@home — about task duration:

With respect to task durations, Rosetta@home works differently from any other DC project. Tasks run more or less exactly for a fixed, predetermined time, by default for 8 hours. This is independent of the speed of your CPUs.

Why does this happen?

Each task analyzes a certain computational model. Not just once though, but actually several times in succession. Each time, different start parameters are fed into the model. These parameter variations are called "decoys" in Rosetta's terminology.

Built into the Rosetta application is a watchdog which periodically checks how much CPU time was already expended by the decoys which were completed within a task so far. If the watchdog determines that another decoy would overrun the target CPU time (default: 8 hours), then it quits the task and marks it ready to be uploaded for the boinc client.

Fast computers and slow computers will behave identically in this respect. Except that fast computers will accomplish more decoys within the target CPU time, while slow computers get fewer decoys done.​

What about credits for the tasks, if they all take the same CPU time?

Credits depend (a) on how difficult the particular model within the task is computationally, which depends on complexity of the analyzed protein, and (b) on how many decoys were completed before the task exited.

Fast computers which get more decoys done, get higher credit per task on average, compared to slower computers.​

Why 8 hours?

The project scientists and admins chose this as their preferred compromise between how many decoys typical computers accomplish at typical model complexities, how much time goes by on average between sending tasks to hosts and receiving results from them, and how frequently hosts have to contact the server to request and download work, and to upload and report results. They also considered computers which run only during typical work hours of their owners.​

But wait, it was hinted here that the task duration can be reconfigured by users, wasn't it?

Indeed! Years ago when the watchdog was implemented in Rosetta, the developers and admins decided to expose the target CPU time to contributors as a configuration option, allowing them to deviate from the default if they use their computers in a different manner than the project developers anticipated.

The setting is located at the user page at the Rosetta@home web site, in "Rosetta@home preferences". You can choose non-default target CPU times anywhere between 2 hours or 36 hours.​

If I change this setting, when does it take effect?

First, the boinc client on your host needs to read the setting from the project site. This happens as soon as the client contacts the project server, e.g. when it requests new work, reports results, or if you trigger a project update with boincmgr.

Then, the new setting will affect any tasks which are started after this, as well as any tasks which are resumed after this. That is, the changed setting will affect all tasks which you download afterwards, as well as all tasks which you downloaded earlier but weren't started yet, but also tasks which you already downloaded earlier, then suspended, and resumed* after you changed the setting (source).

You need to be cautious if you decrease the target CPU time: If you resume* tasks which already consumed more CPU time than the new target time allows for, then you may be lucky and such tasks finish right away and get reported as proper results. Or you may be unlucky and such tasks quit with an error, and all the computer time spent for them will go to waste.

*) Edit, this applies to tasks which were suspended to disk, but AFAIK not to tasks which were suspended to RAM. Tasks are suspended to disk, not to RAM, if the computing preference "Leave non-GPU tasks in memory while suspended" is off, or/and if the suspension happens due to client shutdown.​

Nope, it doesn't seem to work. I changed the target CPU time, but boincmgr shows old tasks as well as newly downloaded tasks still with the same old estimated time remaining.

Oh, it does work, it merely doesn't look like it for a while. This is the biggest caveat of this Rosetta@home feature:

While the tasks themselves are affected as described above, the runtime estimation of boinc-client is not influenced by a change of this setting. Boinc-client merely recalls how long Rosetta tasks used to take in the past, and assumes that new tasks will take just as long. The client will require a very long period of observing further tasks in order to gradually adapt its runtime estimation.

Consequently, not only does boincmgr show estimations which may be way off, but boinc-client is also highly confused when it is meant to fetch work for a buffer of n days duration. It will fetch far too few tasks, or far too many tasks, depending on whether you decreased or increased the target CPU time, and by how much you changed it.

The Rosetta@home admins therefore recommend (a) to consider leaving the target CPU time at the default, (b) if you still want to, to change it only gradually rather than in one big step, (c) to have a rather small workqueue buffer setting in your client while you perform the transition to a different target CPU time.​

But I'd like to set 24 or 36 hours now, at least for the 3 days bunkering period before the Pentathlon starts.

By all means, do it. Just keep in mind that you need to closely check how many tasks to download for your bunker. Boinc-client won't be able to get this right without your intervention.

Also note: Some tasks may run considerably shorter than for the target time. It sometimes happens that fewer decoys make sense in a given task than would fit into the target time; these tasks quit early. To address this, perhaps fetch a few more tasks than needed if they all ran exactly for the chosen target time. But on the other hand, don't fetch too many. It would be detrimental to the project if many tasks won't be completed within their deadline of 3 days.​

I read on the Internet that a target CPU time of n hours gives best credits.

There are a lot of bogus claims to be found on the Internet. Check these claims; I guarantee you that they are never based on a sound analysis, which would have to take the huge variability of Rosetta workunits (because of differently complex molecules) into account.

As I said above, the credit scheme at Rosetta@home is designed to be proportional to the number of completed decoys in a result, making it independent of target CPU time.​
 
Last edited:
  • Like
Reactions: TennesseeTony

Markfw

Moderator Emeritus, Elite Member
May 16, 2002
25,483
14,434
136
Well, I got windows 10 installed on the 7452, and it boots, but no internet, no drivers, and its not supported. So I may have to skip all those verification's, and install mint 19.2. Normally, I like to check temps, benchmark, etc. But I guess I will have to do it under linux.
 

Endgame124

Senior member
Feb 11, 2008
954
669
136
Well, I got windows 10 installed on the 7452, and it boots, but no internet, no drivers, and its not supported. So I may have to skip all those verification's, and install mint 19.2. Normally, I like to check temps, benchmark, etc. But I guess I will have to do it under linux.

What is a 7452? Vendor model number, or chip model?