I have no details on the specific WUs or issues they are having. But I wanted everyone to know that BOINC Manager's "estimated runtime" is really based on history, not the present. So, regardless of the name or likely success of current WUs, if BOINC Manager has a recent history with WUs taking 3 or 4 hours longer than the runtime preference, it will "estimate" future WUs will take 3 to 4 hours longer as well. The likelihood of the current WUs running long is not related to the estimated runtime of the BOINC Manager. If the name of the current tasks has the same prefix as those that you had trouble with, that would be a better indicator for you.

I have no details on the specific WUs or issues they are having. But I wanted everyone to know that BOINC Manager's "estimated runtime" is really based on history, not the present. So, regardless of the name or likely success of current WUs, if BOINC Manager has a recent history with WUs taking 3 or 4 hours longer than the runtime preference, it will "estimate" future WUs will take 3 to 4 hours longer as well. The likelihood of the current WUs running long is not related to the estimated runtime of the BOINC Manager. If the name of the current tasks has the same prefix as those that you had trouble with, that would be a better indicator for you.

I have no details on the specific WUs or issues they are having. But I wanted everyone to know that BOINC Manager's "estimated runtime" is really based on history, not the present. So, regardless of the name or likely success of current WUs, if BOINC Manager has a recent history with WUs taking 3 or 4 hours longer than the runtime preference, it will "estimate" future WUs will take 3 to 4 hours longer as well.

For me the problem is not the runtime of wus (i know the decoy's question), but the validation error.

I found 1 "Invalid" run that you were granted 587.11 credits. Were there others that were a problem for you?
Seems like the 587 credits were similar to the other valid jobs.



name T1000_full3_aivan_SAVE_ALL_OUT_03_09_677955_5874
application Rosetta
created 14 Jul 2018, 8:17:20 UTC
canonical result 1015258491
granted credit 587.11

https://boinc.bakerlab.org/workunit.php?wuid=914821393

If running fewer concurrent tasks improves credit per minute, it would imply either memory contention, or L2 cache contention. If all of the cores are operating in the same L2 cache, then you can see how that would become the constrained resource. I don't mean to say there is anything wrong with a given computer, just that R@h is very memory intensive. Also others have found that machines with larger L2 caches seem to yield more credit per FLOPS rating per runtime minute.

Since many of you seem interested, and mystified by the credit system at R@h, I'll try to clarify a few points. Some other projects simply use CPU seconds, or FLOPS of a task to issue credit. The problem with such a system is that it doesn't reward machines that achieve more work per second due to CPU cache, and memory available. It also depends upon the BOINC Manager to track and report the FLOPS expended on a task, and so some users began to falsify the FLOPS benchmarks and thus the FLOPS of their reported results.

To avoid these problems and design a credit system that would work going forward through new generations of hardware and capabilities, a system was adopted whereby credit granted is based on what OTHER user's machines have claimed for how difficult it is to complete each decoy (or model) of a task. The average of the results reported before you is used, rather than an arbitrary benchmark. So the credit granted does not favor a specific CPU type or operating system. It truly is based on completed work. Some tasks use different algorithms to compute their results. Assessing the effectiveness of a variety of algorithms is how the science progresses. This results in variations on computing resources required to complete them. Each type of task self-adjusts the credit it awards.

This makes a credit system that is great at reflecting the value of work to the Project Team, but makes it more difficult to benchmark your own machines. To do that well, you would have to run the same task, from the same starting seed for each benchmark run, and then compare CPU and wall-clock time, as well as the number of decoys produced. The BOINC Manager doesn't have a means of easily supporting this type of usage. Running tasks for other projects or a different class of proteins only tells you about those things. One machine might be faster than another at one type of work, and not with another type. The R@h credit system reflects the value of the outcome, without bias.

I need a working credit system to evaluate which CPU, GPU, OS to use with which project to make it as effective as possible.
I remember that when I was running SIMAP I could see, based on credit I got, that my AMD FX8350 was more effective than Intel 3770K so based on that I used my FX8350 to run work units under SIMAP.

I think everyone would like that. 8-) Even those running the projects. It is very difficult to do.


On Win10 I use the Windows TASK MANAGER to monitor especially the DISK and NET usage. I check out any activity on either one of those.
I use BoincTasks to monitor BOINC WU. I watch the CPU usage of GPU task and MEMORY use of WU.
Einstein GPU tasks take 99% of a CPU and about 1GB of virtual memory on my machine. MilkyWay uses 0% CPU.
Rosetta WU MEMORY usage seems to bloat up to 1GB+ just before CHECKPOINTING.

I use GPU-Z to monitor the loads on the GPU and memory traffic.

I back off the CPU available to CPU jobs until I see the TASK MANAGER CPU drop below 100% and then add a CPU back in. For my 12-core i9-7920X, I had to exclude 2 threads from BOINC CPU WU.

The PROJECTS tend to optimize for a single thread which likely negatively affects the total throughput.
PrimeGrid aggressively prefetches all the data into the CPU caches before starting to crunch.
If you run 1 PrimeGrid WU per CORE, you get shortest compute time.
If you run 1 PrimeGrid WU per THREAD, there is an 80% slow down. You do more work if you use all the THREADS. Just slower.

Many projects break off a fixed length problem and allocate to the volunteer.

Rosetta gives a computer a LONG WU problem and a TIME PERIOD to work on it. If you set your computer TIME to 24 hours, you will see many WU finish much sooner than 24 hours. When I was looking at Rosetta performance, I used a shorter fixed problem where the run time was repeatable and comparable.

Rosetta has a big code footprint. They compile with high optimizations and aggressive INLINE options.
Rosetta does very little floating point. When it does, it does 3D coordinate floating point LOAD, ADD/SUB/MUL, STORE .... 3 times in a row.

When I looked at the new 4.0 version, It spends a significant amount of time spinning on LOCKS. 4.0 seems to do even less floating point.

Here it seams that an Intel(R) Celeron(R) CPU G1620 @ 2.70GHz [Family 6 Model 58 Stepping 9]
(2 processorer) ar producing more than twice the credit as I get running an 15 core (32 thread) @4GHz AMD Threadripper on full load or should I take it that
a Threadripper is a bad choice regarding efficiency if you want ro run Rosetta?

That is my problem, as I use credits to check my equipment. I never know whether what I am seeing is real, or a figment of the imagination.