WCG now appears to be trying to get more useful work done by sending mostly tasks with small total sizes of the input files, such as tasks for the OPN1 subproject.

Is that what others are also seeing?

Not especially. My machine is set to process 4 WCG tasks at a time and is currently running
2 ARP1 and 2 OPN1 tasks. (and one more OPN1 ready to go.) True, I get fewer of the ARP1 tasks, sometimes none. Most of the time when my Boinc-client requests more work, it does not get any.

It is also runninig 4 Rosetta 4.20 tasks. Three 14res_af and one SRS9mpnn.

---

WCG now appears to be trying to get more useful work done by sending mostly tasks with small total sizes of the input files, such as tasks for the OPN1 subproject.

Is that what others are also seeing?

Not especially. My machine is set to process 4 WCG tasks at a time and is currently running
2 ARP1 and 2 OPN1 tasks. (and one more OPN1 ready to go.) True, I get fewer of the ARP1 tasks, sometimes none. Most of the time when my Boinc-client requests more work, it does not get any.

It is also runninig 4 Rosetta 4.20 tasks. Three 14res_af and one SRS9mpnn.

They're now back to tasks for at least three sub-projects, at the cost of much less total work.

The ARP1 tasks now seem to be only retries for tasks originally sent out about a week ago.

Download problems again.

Thanks, but it doesn't work for me. Also, I can't attach to any location except "school", even if I detach from the project and reattach.

EDIT: I can change locations by "resetting" the project, instead of detach/reattach.
But even that trick worked only on my Win10 machine, not my Ubuntu 20.04 machines.

Weird, because I am using default profile and all I did was recheck rainfall and save and then uncheck it and save and the use BOINC to update.

Weird, because I am using default profile and all I did was recheck rainfall and save and then uncheck it and save and the use BOINC to update.

Something must be stuck on my account in their server. But it is not the worst problem they have.
It will eventually get cleared out. Thanks.

---

WCG now appears to be trying to get more useful work done by sending mostly tasks with small total sizes of the input files, such as tasks for the OPN1 subproject.

Is that what others are also seeing?

Not especially. My machine is set to process 4 WCG tasks at a time and is currently running
2 ARP1 and 2 OPN1 tasks. (and one more OPN1 ready to go.) True, I get fewer of the ARP1 tasks, sometimes none. Most of the time when my Boinc-client requests more work, it does not get any.

It is also runninig 4 Rosetta 4.20 tasks. Three 14res_af and one SRS9mpnn.

They're now back to tasks for at least three sub-projects, at the cost of much less total work.

The ARP1 tasks now seem to be only retries for tasks originally sent out about a week ago.

Download problems again.

I'm not doing ARP. Just the others.
Grinding through them just fine.
Getting mostly OPN.

is it just my machines that seem to get flat out 0 work from Rosetta for the last 2 days (ongoing issue)?
Other projects work fine

Rosetta has run out of work about two days ago, always check the server status page in case you don't get work, usually you'll find the reason there.

---

.

Rosetta is out of work, DENIS has a model problem, COSMO has a SSL problem, what else is going on out there with problems? Seems like you need 12 projects to get 8 of them with work at any given time.

Rosetta has run out of work about two days ago, always check the server status page in case you don't get work, usually you'll find the reason there.

Do You think it is an intermittent shortage or is the project heading into a sunset?

Rosetta is out of work, DENIS has a model problem, COSMO has a SSL problem, what else is going on out there with problems? Seems like you need 12 projects to get 8 of them with work at any given time.

Einstein@Home seems to have a LOAD of arecibo WU's since they have a new PhD there now crunching the data

Multithreaded CPU applications can use multiple CPU cores at once if the application is written to allow this. The main restriction on these is that no two virtual cores within a physical core can execute an instruction at the same time. However, main memory speed is usually such that any virtual core waiting on a main memory access will not have to wait any longer if another virtual core for that physical core can get its inputs from a cache instead of main memory.

My processor has 16 cores and currently I allow 11 of them to run boinc tasks. Currently, the work is like this:

    PID    PPID USER      PR  NI S    RES  %MEM  %CPU  P     TIME+ COMMAND                                                   
 276543   18589 boinc     39  19 R 411784   0.6  99.0  0 365:00.07 ../../projects/boinc.bakerlab.org_rosetta/rosetta_4.20_x+ 
 272100   18589 boinc     39  19 R 334292   0.5  99.2 15 398:23.28 ../../projects/boinc.bakerlab.org_rosetta/rosetta_4.20_x+ 
 278211   18589 boinc     39  19 R 329396   0.5  99.5  8 332:35.08 ../../projects/boinc.bakerlab.org_rosetta/rosetta_4.20_x+ 
 282712   18589 boinc     39  19 R 329016   0.5  99.5  1 239:43.68 ../../projects/boinc.bakerlab.org_rosetta/rosetta_4.20_x+ 
 294398   18589 boinc     39  19 R 117612   0.2  98.5 11   1:34.50 ../../projects/www.worldcommunitygrid.org/wcgrid_opn1_au+ 
 294358   18589 boinc     39  19 R 114536   0.2  99.2 13   2:33.49 ../../projects/www.worldcommunitygrid.org/wcgrid_opn1_au+ 
 294415   18589 boinc     39  19 R 113492   0.2  98.6  5   1:02.63 ../../projects/www.worldcommunitygrid.org/wcgrid_opn1_au+ 
 289788   18589 boinc     39  19 R  73000   0.1  99.3  4  92:44.43 ../../projects/www.worldcommunitygrid.org/wcgrid_mcm1_ma+ 
  18589       1 boinc     30  10 S  39016   0.1   0.2  8  39924:11 /usr/bin/boinc   <---<<< BOINC CLIENT                                  
 292098   18589 boinc     39  19 R   7136   0.0  99.3  3  43:46.18 ../../projects/milkyway.cs.rpi.edu_milkyway/milkyway_1.4+ 
 293586   18589 boinc     39  19 R   6996   0.0  99.2  6  12:04.72 ../../projects/milkyway.cs.rpi.edu_milkyway/milkyway_1.4+ 
 293296   18589 boinc     39  19 R   4876   0.0  99.6  2  18:16.38 ../../projects/universeathome.pl_universe/BHspin2_20_x86+ 

Only a little over 11% of cache references are misses. Other tasks, expecially N216 CPDN tasks hit the cache very hard.

# perf stat -aB -e cache-references,cache-misses
 Performance counter stats for 'system wide':

     5,688,852,727      cache-references                                            
       632,547,182      cache-misses              #   11.119 % of all cache refs    

      61.181304830 seconds time elapsed

Computer 5910575
Computer information

CPU type 	GenuineIntel
Intel(R) Xeon(R) W-2245 CPU @ 3.90GHz [Family 6 Model 85 Stepping 7]
Number of processors 	16

Operating System 	Linux Red Hat Enterprise Linux
Red Hat Enterprise Linux 8.6 (Ootpa) [4.18.0-372.26.1.el8_6.x86_64|libc 2.28]
BOINC version 	7.20.2
Memory 	63772.81 MB
Cache 	16896 KB   <---<<<

---

Rosetta has run out of work about two days ago, always check the server status page in case you don't get work, usually you'll find the reason there.

Do You think it is an intermittent shortage or is the project heading into a sunset?

As far as I know, the WU supply with Rosetta tasks has been intermittent since a while, that does not need to mean, they will shut down soon. It just means they have no work right now, this might happen at any project.

---

.

Rosetta has run out of work about two days ago, always check the server status page in case you don't get work, usually you'll find the reason there.

Do You think it is an intermittent shortage or is the project heading into a sunset?

As far as I know, the WU supply with Rosetta tasks has been intermittent since a while, that does not need to mean, they will shut down soon. It just means they have no work right now, this might happen at any project.

There really is nothing quite so tiresome as random people claiming the project is going to close down because they had a period with no tasks.

A reminder of the status of the project posted here 28-Sep-2022

There are plans for more python tasks, but we are still working on creating the new disk image for the VM.
This image will likely be larger in size since we hope to run some of the latest deep-learning based methods for protein design and validation.

Computing resources are still very much in high demand within the Baker Lab and IPD so Rosetta@home will definitely help once we can get the latest software set up and running.

Also, the standard rosetta application is currently being worked on for an update.
The IPD has hired a software developer specifically to help expedite this.

I am not sure about timelines at the moment but hopefully there should be updates to both projects/apps within the next month or so.

David Kim

If an update to the VM for python tasks and taking a developer on to update the Rosetta app is a sign of heading into a sunset, then yes.
More obviously it's the opposite, so no.

Since that statement was originally posted we've had the largest drop of new tasks for quite some time.
It's always difficult to hold people to timelines on a project that's always been at the cutting edge, so while I'd hope we'll see something in November, it might be more realistic to expect something this side of the new year. It gets here when it gets here

---

If an update to the VM for python tasks and taking a developer on to update the Rosetta app is a sign of heading into a sunset, then yes.
More obviously it's the opposite, so no.

Since that statement was originally posted we've had the largest drop of new tasks for quite some time.
It's always difficult to hold people to timelines on a project that's always been at the cutting edge, so while I'd hope we'll see something in November, it might be more realistic to expect something this side of the new year. It gets here when it gets here

The death of Ralph@home is not a good sign...

---

There really is nothing quite so tiresome as random people claiming the project is going to close down because they had a period with no tasks.

Not sure as the front page and server status page haven't been updated quite yet, but another batch of tasks seem to be coming through

---

The death of Ralph@home is not a good sign...

Can something that was never really alive be said to have died?
I never joined it. If I had, I'm not sure I'd ever have noticed.
Unless there was ever some golden era I'm completely unaware of over the last 14 years

---

The death of Ralph@home is not a good sign...

Can something that was never really alive be said to have died?
I never joined it. If I had, I'm not sure I'd ever have noticed.

No, no, i'm wrong!!
Today, just for curiosity, i opened the link and Ralph is online!
After months is back!

---

Bu last workunit was returned at 07-31
https://grafana.kiska.pw/d/boinc/boinc?orgId=1&var-project=Ralph@Home&from=now-6M&to=now

Bu last workunit was returned at 07-31
https://grafana.kiska.pw/d/boinc/boinc?orgId=1&var-project=Ralph@Home&from=now-6M&to=now

That's not a problem.
Ralph has not a lot of work

---

wow..17 tasks available..whoopie!
Where do you see the so called upcoming RAH stuff?
I looked randomly up to page 17 of Robetta and all I see is neural network stuff.
So either I am looking in the wrong place or something does not add up.