I have just received a few rosetta beta tasks.

-First, i never signed up for a beta.
-Second, i set me target runtime to 4 hours for a reason. My computer is not on at week ends and i don't want to run it at night

Is there anything i can do about that, dear crunchers ? (since the rosetta personnel is absent from this zombie forum)

The disrespect of the rosetta team towards its volunteers is staggering and getting worse and worse.

---

-First, i never signed up for a beta.

They are released here on main, so that's why you end up getting them.

-Second, i set me target runtime to 4 hours for a reason. My computer is not on at week ends and i don't want to run it at night

Is there anything i can do about that, dear crunchers ?

Other than a more powerful system, no. The default time is 8 hours, to allow less powerful systems to produce useful work- that was from the earlier Rosetta & Rosetta Mini Tasks.
Looks like these ones require more work than the older types to process.

Although sorting out what else is using up your CPU time would help- it takes your system 9 hours to do 7 hours of work. Either figure out what else is using the CPU time, or reduce the number of CPU threads BOINC can use so it's not being impacted by the other work the CPU is doing.

---

Grant
Darwin NT

Thanks for your answer.

I have set boinc to use 100% of the threads which means it runs 9 or 10 tasks in lieu of 8 because of the GPU tasks. I can free a thread for the GPU.

But that doesn't change the fact it is bypassing my set target runtime.

---

But that doesn't change the fact it is bypassing my set target runtime.

That has always been the case if the Task has yet to produce a valid result within the set runtime.
There have been batches of work over the years where even on a high performance system, some Tasks have taken 10-12 hours to produce a result.
The most recent batches of work (when there has been work), tended to often only run for 6 hours or so, even if you set a Target run time of 24 hours.

Keep in mind the terminology used- Target Runtime- it is not, nor has it ever been, a hard limit. It is only a target.
Given that you run multiple projects there is no need for a cache- Just set your cache to 0 days & 0.01 additional days, and even if Tasks were to run for 3 or 4 times your Target Runtime, they still won't run in to deadline issues.

---

Grant
Darwin NT

target time 8H , actually, some WU takes 18h !

Again, tasks which bypass my set time. I have cancelled half of them and set rosetta on no new tasks.

---

Again, tasks which bypass my set time. I have cancelled half of them and set rosetta on no new tasks.

The problem is the use of decoys: Rosetta Decoy

---

Again, tasks which bypass my set time.

And once again- it is not a set time, it is a target time.

I have cancelled half of them and set rosetta on no new tasks.

If you can't deal with the fact that it is a target time, not a set time, then that would be for the best.

---

Grant
Darwin NT

Windows 11 has a bug in which it misreports cpu time. For example task is running for 12:36:00 but cpu time is 7:20:00

Windows 11 has a bug in which it misreports cpu time. For example task is running for 12:36:00 but cpu time is 7:20:00

The first is the run time, the 2nd the CPU time (and that's the target, not the run time, even if it's written like that in the preferences). Nothing different from other Windows version, but perhaps you should check what is using so much CPU time on your computer and if it might be a good idea to leave an empty core or two for it.

---

.

Windows 11 has a bug in which it misreports cpu time. For example task is running for 12:36:00 but cpu time is 7:20:00

The first is the run time, the 2nd the CPU time (and that's the target, not the run time, even if it's written like that in the preferences). Nothing different from other Windows version, but perhaps you should check what is using so much CPU time on your computer and if it might be a good idea to leave an empty core or two for it.

Yeah...
14 hours to do 8 hours worth of work shows a massively over committed system.
Such as several CPU cores doing heavy non-BOINC work (eg Folding@home) and a BOINC GPU application that needs plenty of CPU support, but the same core(s)/thread(s) supporting the CPU are trying to process CPU work as well. And the cores/threads doing Folding@home work are also trying to do BOINC work at the same time.
End result- it takes lots of time to do not that much work.

---

Grant
Darwin NT

It displays incorrect cpu time for me
Also resource monitor drastically misreports cpu load reading if it isn't loaded completely. I have 8 core cpu.

I think it displays everything correctly... on an undercommited 8-core system Rosetta should be using 12.5% of your CPU and FAH probably 25% (2 cores), both get a lot less than that. I recall reading something about some kind of annoying energy saving crap in Windows 11 for applications that use lot of CPU time, but you'll have to google something like that yourself, I don't find it anymore and I'm still on Win10, so no experience with it. Is your CPU even running at full speed? It should be constantly at at least 3.6GHz, boost up to 3.9GHz. The only time I've seen BOINC applications not using a full core was when I limited the CPU speed on my laptop using Windows energy options for it, than I've seen that type of values in task manager as apparently it didn't understand, that that is the current max speed and they are using actually 100% of a core. So my 1st guess is your CPU is running way below it's max speed.

---

.

My machine is currently running like this It has 16 cores. but Boinc applications only get 12.
It is running Red Hat Enterprise Linux release 8.8 (Ootpa). If I read it correctly, each of the processor cores assigned to Boinc tasks runs 98.9% or more. Except for the one that is sleeping.

top - 14:27:27 up 7 days, 20:47,  2 users,  load average: 12.24, 12.26, 12.42
Tasks: 474 total,  13 running, 460 sleeping,   0 stopped,   1 zombie
%Cpu(s):  0.7 us,  0.1 sy, 74.4 ni, 24.7 id,  0.0 wa,  0.1 hi,  0.0 si,  0.0 st
MiB Mem : 128086.0 total,   2581.3 free,   8189.7 used, 117315.0 buff/cache
MiB Swap:  15992.0 total,  15986.7 free,      5.2 used. 118539.8 avail Mem 

    PID    PPID USER      PR  NI S    RES  %MEM  %CPU  P     TIME+ COMMAND                                                                   
 837088    6386 boinc     39  19 R 773348   0.6  99.2  5 326:28.50 ../../projects/boinc.bakerlab.org_rosetta/rosetta_4.20_x86_64-pc-linux-g+ 
 864315    6386 boinc     39  19 R 765812   0.6  99.2  4  26:36.10 ../../projects/einstein.phys.uwm.edu/hsgamma_FGRP5_1.08_x86_64-pc-linux-+ 
 861537    6386 boinc     39  19 R 765640   0.6  99.2 11  60:18.48 ../../projects/einstein.phys.uwm.edu/hsgamma_FGRP5_1.08_x86_64-pc-linux-+ 
 858098    6386 boinc     39  19 R 765436   0.6  98.9 12 100:35.64 ../../projects/einstein.phys.uwm.edu/hsgamma_FGRP5_1.08_x86_64-pc-linux-+ 
 856294    6386 boinc     39  19 R 765412   0.6  98.9  9 117:37.53 ../../projects/einstein.phys.uwm.edu/hsgamma_FGRP5_1.08_x86_64-pc-linux-+ 
 838617    6386 boinc     39  19 R 731504   0.6  99.0  8 312:19.99 ../../projects/boinc.bakerlab.org_rosetta/rosetta_4.20_x86_64-pc-linux-g+ 
 753498    6386 boinc     39  19 S  73196   0.1   0.1 14   0:36.00 ../../projects/www.worldcommunitygrid.org/wcgrid_mcm1_map_7.61_x86_64-pc+ 
   6386       1 boinc     30  10 S  46760   0.0   0.1  9 132996:22 /usr/bin/boinc                                                            
 856262    6386 boinc     39  19 R   4972   0.0  99.1  1 118:11.01 ../../projects/universeathome.pl_universe/BHspin2_20_x86_64-pc-linux-gnu  
 861688    6386 boinc     39  19 R   4480   0.0  99.2  0  57:13.54 ../../projects/denis.usj.es_denisathome/NHuVe_0.03_x86_64-pc-linux-gnu    
 860567    6386 boinc     39  19 R   4292   0.0  98.9  3  73:08.14 ../../projects/denis.usj.es_denisathome/NHuVe_0.03_x86_64-pc-linux-gnu    
 862191    6386 boinc     39  19 R   4276   0.0  99.2  6  48:33.85 ../../projects/denis.usj.es_denisathome/NHuVe_0.03_x86_64-pc-linux-gnu    
 862431    6386 boinc     39  19 R   4244   0.0  99.1  7  45:05.59 ../../projects/denis.usj.es_denisathome/NHuVe_0.03_x86_64-pc-linux-gnu    
 863028    6386 boinc     39  19 R   4244   0.0  98.9  2  35:46.52 ../../projects/denis.usj.es_denisathome/NHuVe_0.03_x86_64-pc-linux-gnu 

---

Using Task Manager, Processes tab with the BOINC manager closed will make it much easier to see what is going on.
On my system with BOINC manager open, on Task manager, 4 Tasks come under BOINC Manager for Windows (33%), and 8 Tasks show under Background processes (8.3% each).
With BOINC Manager closed, All BOINC Tasks show up under Background processes (8.3%) each.


For some reason, your system is only using half of it's available cores/threads (In Task Manager click on Performance tab, CPU, right click on a graph, "Change graph to.." and make sure "Logical processors" is selected. There should 8, and they should all show 100% usage).


Curecoin, Chrome, Nvidia container are all sucking up CPU time (and there are probably more off the bottom of that screen shot).

The end result is that it is displaying the correct CPU time for you- your system is taking up to 14 hours to do 8 hours worth of work because there are more applications running than you have CPU cores/threads available (or another thought- another cause of such behaviour is "Use at most xxx% of CPU time" is set to less than 100%).

In your BOINC computing preferences you need to set your Usage limits to "Use at most 85% of the CPUs" (so there is one thread available for Folding@home) and make sure "Use at most xxx% of CPU time" is set to 100%.
With such a lower clock speed CPU it may be necessary to set the "Use at most" value to 70-75% to allow for system usage & the other programmes you have running in addition to Folding@home.
NB- these values are for having 8 cores/threads available to BOINC. If you continue to only have 4 available, then you'll need to further limit things.

---

Grant
Darwin NT

So my 1st guess is your CPU is running way below it's max speed.

This is what made me think of something other than over committed.

It would still be running at full speed, but if "Use at most xxx % of CPU time" is set to something other than 100%, then the CPU will be running at 100% speed, but the processing will run for a bit, then stop, run for a bit, then stop, run for a bit, then stop, run for a bit, then stop...

The lower the percentage value, the longer the stops, and the shorter the run period.
End result- it takes 9, 14, 16, 24 hours to do only 8 hours worth of work (depending on the less than 100% value used)...

---

Grant
Darwin NT

It would still be running at full speed, but if "Use at most xxx % of CPU time" is set to something other than 100%, then the CPU will be running at 100% speed, but the processing will run for a bit, then stop, run for a bit, then stop, run for a bit, then stop, run for a bit, then stop...

Running not at 100% of CPU time however does not lead to such difference between run time and CPU time, BOINC stops the counter for run time when it tells the app to pause. I was trying that too on my laptop and the result was actually a CPU time, which was higher than the run time, there was apparently some small delay between BOINC telling the app to pause and pausing the run time counter and the app actually pausing, so it was always running always a bit without the run time counter.

---

.

The way I manage my range as a volunteer, I am able to manage it better with WUs lasting around 28000 sec. Then do as you want...

EDIT: and an extension of time, in relation to today's more elastic duration
Thanks
Regards

I would like to add that there is a significant discrepancy in the granting of credits between the 2 types of WUs