Please build a new app for Rosetta-python. Either Docker (for Linux hosts) or PyInstaller to pre-compile statically a python app to run natively without virtualization . (On any hosts)
This native python build should skip VirtualBox completely.

VirtualBox consume a ton of RAM and lowers CPU performance. VirtualBox is great for testing and prototyping but it's a bad idea to run performance intensive workloads on it.

You OBVIOUSLY have NOT been a Boinc cruncher for very long as EVERY Project has experienced shortages of workunits over time, even Seti the first Boinc Project has shut down and is no longer creating any new workunits. In fact there are over 100 Boinc Projects that have started and closed for one reason oranother but yet Rosetta chugs right along still producing workunits!!

As for 3 day dead lines you REALLY need to expand your crunching to other projects, more than a couple have 2 day deadlines that are met by 99% of it's users with no problem. YOUR problem seems to be your unwillingness to adjust to the fact that not every Project is the same or run in the exact same way.

One basic 'rule' of Boinc is to always set your workunit cache to a very small amount until your computer and the new Project can figure out how long each workunit takes to runandwhat cahce size works for you. SEVERAL people have already said that but you STILL seem to be saying the same old thing...adjust to ME not me adjust to you!!!

In short if you can't handle the 3 days deadlines then maybe Rosetta isn't the Project best suited for you and your resources, it works for 99% of the people who are here, so it seems you are the outlier here. Or in Teacher terms YOU are the one screwing up the curve!!!

If you prefer LOOOOOOOONG deadlines why not try Climate Prediction as some of their workunits take over 365 days to complete!!

The AMD EPYC 7Fx2 series is intended for applications that benefit more from frequency and cache, over raw thread count. However, Rosetta@home is perfectly able to use as many threads as a system has available (provided that the machine has sufficient RAM).

While these frequency-optimized SKUs are impressive for their intended workload, they wouldn't be optimal for Rosetta compared to the existing 2nd generation Epyc lineup.

My Android pixel 2xl is an arm64 device but it's not getting any Wu's. Something else I need to do?

The server is currently out of tasks for mobile devices, so you will at least have to wait for more to be created.

I looked at its details. It looks like it should be able to run one task at a time, and possibly two, due to the size or its memory.

You may need to get familiar with the settings that control the limit of how many tasks it will try to run at the same time.

I'm not sure I'd use this on my primary phone, just because of heat and battery issues even though it only runs when plugged in... BUT, I did have 2 older phones that I should have recycled long ago in my desk drawer. They are now setup to run this on the corona project 24/7. If those older phones die no big deal.

Is the "Current GigaFLOPS" stat in the Server Status page accurate?

No.
Such values are usually derived from the RAC/Credit of the attached hosts, or the Tasks themselves. And due to the broken nature of the BOINC Credit mechanism (just look at the huge variability of Credit granted here for different Tasks and different Applications) any such claims of compute performance need to be taken with an ocean of salt. And then you have other BOINC projects that grant Credit in their own way, making their claims of compute performance to be complete and utter fantasy with no basis in reality.
The variability of Rosetta Credit makes me suspect they are using the BOINC Credit New mechanism, which tends to underpay significantly, and as Credit is used to determine FLOPs...

I mean 1 GFLOP reported here = 1 GFLOP reported by Folding@Home.

I've no idea how Folding@home come up with their FLOPs numbers- if they use FLOP counting then they should be pretty close to the true value. If they use some other mechanism then all bets are off.
But the FLOPs between the projects are nowhere near comparable due to the different methods of coming up with the value; you can't even compare FLOPs between BOINC projects, let alone projects outside of the BOINC framework.

So, am I supposed to update my client to participate in this new capability? Kind of confused as to whether this is a call to action or just a status update.

Hi all! First time I've used Rosetta@home in a while in light of COVID. I had a technical question. My computer has 4 CPUs and an AMD GPU (which my understanding would suggest that the GPU isn't particularly used by Rosetta@Home).

To optimize Rosetta@Home, would it be better for me to dedicate 1 or 2 of the CPUs at 100% CPU Time or to dedicate all of my CPUs at 50% CPU Time? Is there even a difference?

Thanks!

Hi from Germany!
Not new to BOINC, but new with R@H since... we all know when.

Stay safe and healthy, everyone!

It's not the virus that concerns me, it's the world falling apart due to virtually nobody working. I already find it hard to buy food, a freezer, a home gym, or brewing sugar. Panic is always worse than the actual thing.

Currently, I have 14 machines with 80+ cores and 14+ GPUs. When I switched over to run one of them to Rosetta, from cancer research (WCG), I did NOT receive anything related to covid19. Whenever I would receive ALL WUs for covid19, I will switch over... Till then I will stick with cancer research. Let me know when covid19 is the priority here. I am NOT going to download the fold@home app. If it is not thru BOINC, I do not run it.
James

There has been a discussion that Folding@home is likely to produce a BOINC version soon, Not ready yet, though.

Is that right? That's a project I've always wanted to run - especially now they're doing COVID work - but I've also been put off by it not being available via Boinc

Quick question for anyone, yesterday when it became clear that the server was empty I completed my running units, suspended the rest and did a project reset on my fastest set up. My thinking being that I would send my queue back to the server for redistribution. Is that how it works as although my client is empty, I have a considerable number of tasks in the "in progress" section, although I obviously do not. I had to reset the project a couple of times during the last few days as some work refused to download also but that's understandable given increase in users, and it seems that whatever was in the queue is also listed in that section?

So when you reset does the client not tell the server to redistribute the work you had waiting?

Not only has the coronavirus spiked volunteer interest with our R@h project, but it is also spiking a lot of interest towards R@h within the lab so the communication should definitely get better. A lot has happened in a short amount of time.

1. As mentioned before we spiked ~4x or more in computing in the last week. So far our infrastructure has been handling this okay but we will definitely look into expansion and optimization as we expect many more volunteers to join in the near future. Also, our bandwidth has maxed out on a few occasions but has been okay since.

2. A number of outside groups have approached us to help.

a. The ARM developer community came together and helped port Rosetta for aarch64. The application is being tested on Ralph@home currently and will be released soon along with an announcement.
b. We are in communication with Microsoft to help us integrate and support Rosetta BOINC builds into the Rosetta Commons build and testing infrastructure and possibly with other developments.
c. We are in communication with Charity Engine to possibly use their infrastructure to run GPU machine learning based jobs and to help integrate such capability to R@h.

3. We have plenty of COVID-19 jobs but there may be a pause from time to time to give us a chance to prepare them based on previous results and new targets/methods etc.
4. We hope to update the Rosetta apps that are currently being tested on Ralph soon and plan to do another update in the near future, so 2 application updates are lined up for the near future.
5. With these updates, we hope to recruit more researchers within the lab to use this resource, but in the immediate future, priority will of course be towards COVID-19, specifically for the design of scaffolds and binders to COVID-19 targets as possible therapeutics.

Thanks Everyone!

My computer does not receive new jobs, maybe they are over. Waiting from China for i5-4690 instead of G1840.

team Challenge
https://www.boincstats.com/stats/challenge/team/chat/1074

To try and maximize my contribution to fighting SARS-CoV-2, I've adopted the approach of running R@h for CPU work, and running Folding@home for my GPUs

Much thanks to the R@h team!

Sorry, I leave this projet.
Admin publish information as links. Nice to be informed about . The latest is three years old !!!
The only recent (16july19 by admin) is about "audacious projects". Nice, but is not a part of Boinc.
And this link send us to donation requests !

And about projects who has nothing to do with sciencetific research, as educating people, sexual abuse,...
Of course there are also very important subjects, but
Does we think they not need the computing power of Boinc ?

But what they do to solve the problems of a lot of users ? Abnormal running, app crash,......
Nothing ! Or even good as nothing.Never answer about technical problems. The admin fully ignare the Boinc cruncher.
They just ignore us !

Well, you can't execute the benchmark since that are all your completed WUs. Whatever you did, will sort itself out with time.
You can force 64-bit only with <no_alt_platform> in cc_config.xml, but I would wait with that and see if the 64-bit application is really faster than the 32-bit, that's not always the case. Just watch the GFLOPS values. If it really is faster, the server will send most WUs to that application anyway, so no really need to do anything.

I was surprised to see that Rosetta 4.08 is the only 64-bit binary for Linux. Both copies of Minirosetta are 32-bit.
The 32-bit binaries end up with a smaller code footprint and pass parameters on the stack. The parameter list quickly spills to the stack, but they will be in the L1 cache which has a 1-cycle access time.

A 64-bt version will always be faster if compiled properly, unless you aggressively inline functions. The larger code footprint is causing front-end icache miss stalls.
I want to see how hard it is to modify the source to redefine their 3-dimensional "vector" object into a 4-dimensional vector so they can use packed SSE or AVX. Right now all Rosetta computation uses scalar operations.

thanks again.