The selection of "bad" tasks is very efficient.

VERY efficient. It's up to the volunteers to kill the bad tasks. VERY efficient.

The price paid is in bandwidth of Windows users, that's true, but nothing more.
I don't personally consider people's frustration to be worth a second thought

Yep, 3 days of waste of time and bandwidth WITHOUT ANY APOLOGIES from project it's "nothing more".
Thank you for your considerations of volunteers
Are you speaking on behalf of the project administrators? If yes, it's very serious.

---

.Can you try to change use at most memory setting in computing preferences > disk and memory?
You have hidden your computers so i can't see them.

Use at most setting for memory is set to 99% and 100% for the CPUs. Server has 128 threads and 256GB of memory yet only 17 tasks are running. No message in log indicating that BOINC is waiting for any resource. Boinc has copied the VDI file to 88 slots result in about 697GB of used disk space. Disk is a 900GB disk. Boinc told to leave 1% free as the most restrictive parameter.

.Can you try to change use at most memory setting in computing preferences > disk and memory?
You have hidden your computers so i can't see them.

Use at most setting for memory is set to 99% and 100% for the CPUs. Server has 128 threads and 256GB of memory yet only 17 tasks are running. No message in log indicating that BOINC is waiting for any resource. Boinc has copied the VDI file to 88 slots result in about 697GB of used disk space. Disk is a 900GB disk. Boinc told to leave 1% free as the most restrictive parameter.

What else is running on your system? How much memory debt do you have to other programs and OS requirements? In theory, with nothing else running, you should be able to run around 100 pythons, but maybe Vbox can't handle that? 88 slots, so you have 88 tasks downloaded, but can run only 17?


I'll leave this for the experts to work on...I think, but can not say for sure that Vbox might be the limiter.

Are the vbox tasks limited as to how many can run concurrently. Can only get 17 to run at the same time. All others are in "waiting to run" status in BOINC. No app config file in the projects directory.

Each of them reserves a large amount of memory, almost 8 GB. Unless that amount of memory is free, they won't start, even if they would shift to using much less memory if they did start.

My two tasks allocate 6144

Are the vbox tasks limited as to how many can run concurrently. Can only get 17 to run at the same time. All others are in "waiting to run" status in BOINC. No app config file in the projects directory.

Each of them reserves a large amount of memory, almost 8 GB. Unless that amount of memory is free, they won't start, even if they would shift to using much less memory if they did start.

There is 202GB of free memory as of this writing. BOINC client was not acting correctly so I restarted the client. It took almost 15 minutes for the client to restart the 17 VBoxHeadless processes. During the restart the client runs 100% busy and BOINCMgr is totally unresponsive. However, one you let the processes complete the startup and the boinc process drops back to under 5% utilization you can start more processes. Starting 10 processes causes the boinc process to jump back to 100% busy for about 10 minutes. Once the client drops back to 5% the tasks show as running. It seems to be related to BOINC and VBox. I/O is negligible during the starting of tasks. I think I can baby sit this thing and get it to where I want it.

Thanks for the insights.

The selection of "bad" tasks is very efficient.

VERY efficient. It's up to the volunteers to kill the bad tasks. VERY efficient.

I'm a bit confused. All contributors offer their time and resources to the project.
So if it's for users (miilions) to sort through runnable and non-runnable tasks so the researchers (a handful) don't have to, that's conforms perfectly.

The price paid is in bandwidth of Windows users, that's true, but nothing more.
I don't personally consider people's frustration to be worth a second thought

Yep, 3 days of waste of time and bandwidth WITHOUT ANY APOLOGIES from project it's "nothing more".
Thank you for your considerations of volunteers
Are you speaking on behalf of the project administrators? If yes, it's very serious.

Lol, if I was I'd have been thrown out years ago.
It's pure pragmatism. If it wasn't for the bad news, there wouldn't be any news at all.
Sorry and thanks for your time and effort.
Bygones.

---

Workunit download size is not very big because all rosetta workunits use persistnt database which is downloaded with first workunit and reused for other workunits.

.Can you try to change use at most memory setting in computing preferences > disk and memory?
You have hidden your computers so I can't see them.

Use at most setting for memory is set to 99% and 100% for the CPUs. Server has 128 threads and 256GB of memory yet only 17 tasks are running. No message in log indicating that BOINC is waiting for any resource. Boinc has copied the VDI file to 88 slots result in about 697GB of used disk space. Disk is a 900GB disk. Boinc told to leave 1% free as the most restrictive parameter.

One thing just discovered - if you specify a maximum amount of disk space for Boinc to use, like 850Gb in your case, Python tasks seem to use more than if you allow for no restriction.
It seems to be a bug/quirk in how Boinc works with Python tasks.
See if it makes a difference

---

Use at most setting for memory is set to 99% and 100% for the CPUs. Server has 128 threads and 256GB of memory yet only 17 tasks are running. No message in log indicating that BOINC is waiting for any resource. Boinc has copied the VDI file to 88 slots result in about 697GB of used disk space. Disk is a 900GB disk. Boinc told to leave 1% free as the most restrictive parameter.

Memory and disk settings look good ,
I can run 43 tasks in 128GB of ram [cpu set for 90% use]
Have you checked for zombie tasks , that is tasks that have hardly any `cpu time` and lots of `elapsed time`
I find they will stop other tasks running
It takes a while to go through the `Running tasks` everyday and abort the zombies [if you get them]

result in about 697GB of used disk space. Disk is a 900GB disk. Boinc told to leave 1% free as the most restrictive parameter.

One thing just discovered - if you specify a maximum amount of disk space for Boinc to use, like 850Gb in your case, Python tasks seem to use more than if you allow for no restriction.
It seems to be a bug/quirk in how Boinc works with Python tasks. see if it makes a difference[/quote]
You can safely set the disk space bigger than the disk , so set "use no more than" to 1000GB and boinc will only use what it needs.
I found a combination that works for me , so try this from my thread on the problem.
https://boinc.bakerlab.org/rosetta/forum_thread.php?id=14903&postid=104879
Use no more than - 1000 GB . . don't worry about setting this BIG.
Leave at least ## GB free . . [untick this box not needed]
Use no more than ## % of total . . [untick this box not needed]
try it , see what happens , pythons are a pain.

I was finally able to get about 54 of the tasks running before it started to allocate into the swap space. I just stopped there to prevent any additional IO due to memory. I may have to cut back a bit as I'm starting to get the "VM Job unmanageable -- restarting later" message. I may cut back to around 32 tasks (256GB / 8GB).

One of your Vbox tasks shows this error in the log: Failed to create the VirtualBox object!

2022-02-17 17:27:44 (8792): Detected: VirtualBox VboxManage Interface (Version: 6.1.12)
2022-02-17 17:27:51 (8792): Error in host info for VM: -2147024891
Command:
VBoxManage -q list hostinfo
Output:
VBoxManage.exe: error: Failed to create the VirtualBox object!
VBoxManage.exe: error: The object is not ready
VBoxManage.exe: error: Details: code E_ACCESSDENIED (0x80070005), component VirtualBoxClientWrap, interface IVirtualBoxClient

2022-02-17 17:27:51 (8792): WARNING: Communication with VM Hypervisor failed.
2022-02-17 17:27:51 (8792): ERROR: VBoxManage list hostinfo failed

Maybe someone else can help him with this?

I seem to have gotten VirtualBox working by doing a few things (so unsure exactly what fixed the VBoxManage.exe errors).

First, I let the last batch of "Rosetta v4.20 windows_x86_64" tasks to complete. Had dozens of "movingstub_..." tasks all fail immediately, and would cause the BOINC GUI to hang without updates while those movingstub tasks would start then fail. So stopped getting new tasks, and then allowed the good tasks to complete. (Went to work and left the system alone.)

Second, reenabled the "VirtualBox VM jobs" by clicking the "Allow" button. New tasks for "rosetta python projects v1.03 (vbox64) windows_x86_64" started to download. These tasks also started failing with more of the failed to create VirtualBox object. Shutdown BOINC so the few remaining tasks would not get a chance to start running.

Third, downloaded and installed the latest BOINC version. This would update my existing from
BOINC_7.16.11_with_Virtualbox_6.1.12 to the next version of
BOINC_7.16.20_with_Virtualbox_6.1.12
Note that the VirtualBox version remains the same. But it is still older than the current available version that VirtualBox says is available when its GUI is started up manually.

Fourth, when running the update executable, I made sure to right click on the installer program and use the "Run as administrator" option.
Previously I have the BOINC program files installed on SSD Drive C: and the ProgramData files on HDD D:
For this install, I also put the Program Files onto D: as well.
I also unchecked the option to to run BOINC in a separate service account, as I think I saw other comments saying that using a service account could be a problem.

Fifth, after the update BOINC seems to start, but not sure if the Rosetta tasks were working. After a minute or so, I shut down BOINC, then rebooted the PC since it has not been required during the upgrade. I figured I should give the system a clean restart anyhow.

Sixth, when BOINC started this time, I manually started the Oracle VM VirtualBox Manager GUI (again, ignoring the message that a newer version is available). After awhile I started seeing VMs getting spooled up one at a time. I had not seen these background VMs appearing before, and the errors make sense if the imagers weren't getting started in the first place. Until I saw the individual VM images listed in the VirtualBox GUI, I was not sure what I would be seeing anything in the leftmost column under the Tools icon. These images were starting up pretty slowly, one at a time, with the HDD activity was maxed out at 100% during each start, and only a brief back off of HDD activity between images starting. So VM spool-up speed seems up HDD bandwidth limited on this system. Eventually 8 images were started, and the HDD activity thankfully dropped greatly. To start off BOINC allowed for 100% CPU activity, which I reduced it to 50% CPU usage. All 8 images kept running, which makes sense, as this machine has an 8 core, 16 thread processor, so 1 VM per core. I then backed off the BOINC CPU usage to 45% so only 7 core would be in use to reduce fan noise slightly and allow other computer activities to have one full core to play with while the VMs ran in the background. (50% / 8 cores = ~6.25% per core, so the 45% limits will only support 7 cores at ~43.75% total.)

So the reinstall made these changes:
- Ran the combined BOINC and VirtualBox installer with Administrator Privileges (not sure if this was done previously).
- The BOINC Version was updated.
- The VirtualBox appeared to have some/all updates run on it as well, including changed to system privileges.
- The BOINC Program Files were placed in a new location.
- The removal of BOINC running in a separate service account.

As BIOS VM support was already turned on, and Microsoft VM support in Windows 10 (Hyper-V ?) was previously removed, the reinstall didn't mess with these other system issues.


With the New Rosetta Python now running, and using the Suspend/Resume button to verify switching between Rosetta and non-Rosetta tasks all run as expected, I just need to wait to see these Python VM Tasks complete and report successfully. But I expect that everything is now running OK.

Finally, on my non-Windows machines the "movingstub_..." tasks were not failing immediately. Some seemed to have completed. Didn't look into it further, but it seems the problem with all the movingstub tasks is related to Linux vs Windows platform differences.

VERY efficient. It's up to the volunteers to kill the bad tasks. VERY efficient.

I'm a bit confused. All contributors offer their time and resources to the project.
So if it's for users (miilions) to sort through runnable and non-runnable tasks so the researchers (a handful) don't have to, that's conforms perfectly.

I give my time and resource to this project before you, it's not a problem.
But i think that a little bit of respect for volunteers is welcome.

It's pure pragmatism. If it wasn't for the bad news, there wouldn't be any news at all.
Sorry and thanks for your time and effort.
Bygones.

Are you inviting me to abandon the project?
I'm italian, so my english is not so good...

---

When i downgrade from latest virtualbox version to 5.2.44 instead of unmanageable errors system begins lagging and beeping https://www.youtube.com/watch?v=wQp1WFeWZCY

VERY efficient. It's up to the volunteers to kill the bad tasks. VERY efficient.

I'm a bit confused. All contributors offer their time and resources to the project.
So if it's for users (miilions) to sort through runnable and non-runnable tasks so the researchers (a handful) don't have to, that's conforms perfectly.

I give my time and resource to this project before you, it's not a problem.
But i think that a little bit of respect for volunteers is welcome.

It's pure pragmatism. If it wasn't for the bad news, there wouldn't be any news at all.
Sorry and thanks for your time and effort.
Bygones.

Are you inviting me to abandon the project?
I'm italian, so my english is not so good...

I've been here a long time. This used to be a project that was progressive in their keeping tabs on things here. But as they have grown more dependant on their neural network, they stopped paying attention here.

The old procedure was to test new tasks on the beta program RALPH. But now it seems to be just put the tasks here without checking them and see what happens.

I wouldn't give up this project, because the science we process for them is useful. It's just a shame they don't communicate anymore.

Rosetta@home: Notice from server
rosetta python projects needs 14411.41MB more disk space. You currently have 4662.07 MB available and it needs 19073.49 MB.
2/16/2022 10:25:14 PM


Say what?
500 GB dedicated drive
Boinc set to leave 2GB free use the rest
Windows says 97.1 used and 358 free out of 465 available

running 10 python and 4x 4.2

Weird

Now that I just got VirtualBox working, I got a similar server message. Went digging into it, and made the following notes:

- - -
Windows 11 file manager stats:
1 TB HDD
264 GB used
667 GB free
- - -
Within BOINC:

Computing preferences for the Disk

[x] Use no more than 100 GB
[x] Leave at least 1 GB free
[x] Used no more than 50% of total


Showing in the tab "Notices"

Rosetta@home: Notice from server
rosetta python projects needs 4874.94MB more disk space. You currently have 14198.55 MB available and it needs 19073.49 MB.
2/20/2022 4:36:59 PM


Showing in the tab "Disk"

Project #1: 530.50 KB
Project #2: 2.18 GB
Project #3: 21.49 MB
Rosetta@home: 83.74 GB

So, Rosetta is using about 95% of the available disk space allocated to BOINC, with a BOINC total of about 86 GB used of the 100 GB limit.

- - -

Re-writing the server notice to be more readable:

rosetta python projects needs 4.87 GB more disk space.
You currently have 14.19 GB available and it needs 19.07 GB.

Not clear where these limits and free space values are coming from. Nonetheless I can easily increase the available HDD space for BOINC usage. Currently still have 667 GB of free space, and no plans to use any of it for now. Changing the Disk settings to only have one limit for at lease 50 GB of free space be left available.

[ ] Use no more than ____ GB
[x] Leave at least 50 GB free
[ ] Used no more than ____ of total

With the old settings, the available HDD limit should have been 100 GB.

With the new settings, the available HDD limit should be ~617 GB, assuming nothing else uses any of the 667 GB of free space currently available.

UPDATE: By listing these different settings and notices in one place, I see the 86 GB used of 100 GB available leaves only 14 GB free. So the notice about 14.19 GB free but needs 19.07 GB for python (VM based) projects now makes sense.


With the increased available disk space change, I now need to wait and see if the server recognizes more space is available, and starts sending out more and/or larger tasks.

@ BoredEEdude
Try this
I found a combination that works for me , so try this from my thread on the problem.
https://boinc.bakerlab.org/rosetta/forum_thread.php?id=14903&postid=104879
Use no more than - 500 GB . . don't worry about setting this BIG. even if you set this bigger than the disk , it works.
Leave at least ## GB free . . [untick this box not needed]
Use no more than ## % of total . . [untick this box not needed]
try it , see what happens , pythons are a pain.

I tried every setting possible [sort of] until I found this simple setup
other settings do sort of work , but boinc does some wakjob cookie maths to get there .
More like mashamatiks
don't let it do your head in

I've been here a long time. This used to be a project that was progressive in their keeping tabs on things here. But as they have grown more dependant on their neural network, they stopped paying attention here.

The old procedure was to test new tasks on the beta program RALPH. But now it seems to be just put the tasks here without checking them and see what happens.

I wouldn't give up this project, because the science we process for them is useful. It's just a shame they don't communicate anymore.

I have also been supporting Rosetta@home for a long time (will be 10 years as of 2022-04-11), but have been thinking lately (without any input except what the program and website statistics indicate) that something about the project's culture seems to have changed.

In the early days, they really seemed to appreciate the huge amount of "free" computational power being made available. Stories of what kinds of results they were getting could be found easily, and it was clear that a lot of the progress being made was because of the computing resources being volunteered. 100% of my many computers were dedicated to processing Rosetta tasks for most of my time here.

When COVID hit, the amount of available resources skyrocketed to "help find a cure" or at least better solutions to the problem. My individual climb up the crunching statistics ladder slowed, stopped, then backslid as all the other resources came online. It was all good, since getting science done was the main thing. Personal credit standing was just a nice-to-see thing, and I knew I would eventually level out at some point below the biggest crunchers. It was also interesting over the years to watch power crunchers with massive server farms rocket up the ladder, then eventually disappear, and finally see their peak ranking backslide down the ladder as new power users appeared with better computers, or how the slow-but-steady crunchers would just continue their slow rise on the rankings ladder.

When GridCoin came along, I also figured what the heck, I may as well try getting some of that crypto for the computer work I'm already doing anyhow. GRC will probably never amount to anything, but one thing it did do was prod me to add on other projects when Rosetta was having an outage and my computers were sitting idle. So it served to open the crack of my previous exclusive support to Rosetta, as other projects got CPU time whenever Rosetta went down.

Now I'm reading about their changing focus (what's this neural network stuff about?), seeing a lot of problematic tasks getting released for days on end with no supervision, and having many of my computers sitting idle from lack of compatible work. Reading that a computational-based project has no dedicated IT support staff (not even 1 part-time individual?), science researchers writing programs (with possibly weak basic computer skills), and expecting the individuals already volunteering their computer resources to be the ones troubleshooting issues back to a project that may not really be listening to that feedback is slightly disturbing.

After getting millions of dollars worth of free computing resources donated, which in turn undoubtedly helped to validate research directions and define individual researcher's careers along the way, I would expect that some small but significant about of support/effort be put into addressing at least the obvious problems encountered by the volunteers to the project. That no one from the project will apparently ever read this comment for themselves would indicate a level of assumed entitlement to those donated resources. Or possibly an expectation of moving away from needing those resources in the future, so why bother supporting them now? Just as SETI@home eventually stopped supplying computational work on March 2020, maybe Rosetta@home is heading in a similar direction at some point?

I will continue to give Rosetta priority over other BOINC projects (for now). But if this project expects to retain this computing capability (from "everyone", not just me), they should start paying more attention to supporting it. Once users start leaving due to no available work, or after a lot of aggravation from bad/useless work (I'm looking at you movingstubb), those users may never return. And I hope we won't see another COVID-type crisis to spike the arrival of new computational donors, so they should be managing the ones they still have more carefully.

@ BoredEEdude
Try this
...
Use no more than - 500 GB . . don't worry about setting this BIG. even if you set this bigger than the disk , it works.
Leave at least ## GB free . . [untick this box not needed]
Use no more than ## % of total . . [untick this box not needed]
try it , see what happens , pythons are a pain.

I changed to using just the "Leave at least _____ GB free" setting about 30 minutes before reading your post about using just the "Use no more than _____ % of total" setting.

As I write this, the BOINC server notice about needing more space has gone away, so I'm assuming my change is working for now. If I get a new server error about lacking space, I will give your approach a try.

I also just saw my first 3 valid python tasks accepted by the server a few minutes ago, so my main problem of VirtualBox tasks not working seems to be fixed. For now I just want to see if everything keeps running smoothly for the next few days. If I keep tinkering with the settings it might just confuse the server further in the short term.