I'm using vbox v6.1. My job requires a lot of virtualisation so I'm always running the latest stable virtualbox.

Interesting that python doesn't like it. I'm running python 3.9.7 which I am guessing isn't "old python".

Any legacy Rosetta is running fine after I made the changes suggested above so I'm happy for the moment. Again, BOINC for me is set and forget - the only thing I adjust is the %CPU it uses on my desktop whilst I'm working. Overnight 100%, email, doco etc it gets 80%, if I'm coding it gets none.

Thanks, Grant.

Well...just let the old pythons pass through your system and let someone else using V5.xx of Vbox run them.
I am on 6.x now of Vbox and I am getting only the new work which is stable.

Looks like we've finished the most recent batch of Rosetta 4.20 Tasks.

---

Grant
Darwin NT

I am running two tasks at a time on my PC with 12 GB RAM. A third one is waiting for more memory but it has done some running too. A fourth one is ready to run.
Tullio

I too was having problems with too many of the vbox jobs trying to run at once, leaving not enough resources resulting in Rosetta and other project tasks not being able to run, resulting in lower overall performance. In my case, lowering Rosetta's resource from 200 (out of 500 - 40% share) to 100 (out of 400 - 25% share) is giving me 10-15% more work completed across all projects. I haven't had any vbox jobs that had to be aborted since then.

BOINC is allowed 11/12 cores, 75% of 32GB RAM. Other projects are WCG and Yoyo.

Yeah, looks like vbox only jobs running. My 8 phyton tasks only show using 20gb ram. It seems vbox reserves so much more ram than it actually uses.

Having great difficulty getting any work, can`t even get pythons on systems that are set up for it [and been running them], anyone else seeing this.
I have seen 5000 python ready to send on the server status page,
most work requests get the `no tasks sent` and no reason why message.

I have been getting pythons regularly (most recently 3 hours ago) on two Ryzen 3900X's. So it much be a machine or network problem.

But the errors ("0 CPU" and "Vm job unmanageable") are getting too annoying for me. I will wait until later to get more, and maybe they will have it fixed. Though they do not even indicate that they know there are problems, so it could be a while.

---

most work requests get the `no tasks sent` and no reason why message.

Do you have any of the "Vm job unmanageable" ones on you machine? That will prevent any more from downloading.
You need to reboot to fix it. Or find another project.

---

most work requests get the `no tasks sent` and no reason why message.

Do you have any of the "Vm job unmanageable" ones on you machine? That will prevent any more from downloading.
You need to reboot to fix it. Or find another project.

I luckily have never had any `unmanageable` jobs or things like that,
and I only have 5 error tasks and one of them was `cancelled by server` another three where the `one minit wunders` that run for hours and do nothing , aborted them.
I did reboot the computer earlier today anyway, just in case something had gone funky
Just had a look at the server status, only three R4.2 jobs in que.

Check the details tab of your individual computer(s) on this website and see if "VirtualBox VM jobs" is showing Skip. If you want VM / Python jobs, that has to say Allow

most work requests get the `no tasks sent` and no reason why message.

Do you have any of the "Vm job unmanageable" ones on you machine? That will prevent any more from downloading.
You need to reboot to fix it. Or find another project.

Jim, have a look here at a older reddit thread.
Its to late at night here in the EU to try and understand what this person is saying, but maybe you understand it?

Check the details tab of your individual computer(s) on this website and see if "VirtualBox VM jobs" is showing Skip. If you want VM / Python jobs, that has to say Allow

I have two computers that are worth running VM jobs on and for both of them the button "VirtualBox VM jobs" is showing "Allow"
For some strange reason they stopped getting ANY work, one has now got two ordinary R4.2 tasks ,
The pythons don't want to come out of their cages and get crunched.
It may just be a strange scheduler thing that will work itself out in time.

Check the details tab of your individual computer(s) on this website and see if "VirtualBox VM jobs" is showing Skip. If you want VM / Python jobs, that has to say Allow

I have two computers that are worth running VM jobs on and for both of them the button "VirtualBox VM jobs" is showing "Allow"
For some strange reason they stopped getting ANY work, one has now got two ordinary R4.2 tasks ,
The pythons don't want to come out of their cages and get crunched.
It may just be a strange scheduler thing that will work itself out in time.

Or there were issues with them & they were black listed by the server.

---

Grant
Darwin NT

I had gone as far to untick all the disk space boxes to give it unlimited use of the disk

The boxes aren't tickable, they require values. And one value in any one of the options overrides the values in any of the other two when it comes to what disk space is actually available.

They are quite tickable - there are checkboxes to the left of each value box which turn off corresponding limit.

I was referring to the web based settings.
If you've only got one system, local Setting are ok. More than one, web based settings make life much easier.

web based settings also have same checkboxes for disk and network usage limits as local settings do. At least here on Rosetta server web based settings for BOINC.

I had gone as far to untick all the disk space boxes to give it unlimited use of the disk

The boxes aren't tickable, they require values. And one value in any one of the options overrides the values in any of the other two when it comes to what disk space is actually available.

They are quite tickable - there are checkboxes to the left of each value box which turn off corresponding limit.

I was referring to the web based settings.
If you've only got one system, local Setting are ok. More than one, web based settings make life much easier.

web based settings also have same checkboxes for disk and network usage limits as local settings do. At least here on Rosetta server web based settings for BOINC.

Hmm.
That's new.
Clicked on Edit and up come the check boxes with the value boxes next to them.

---

Grant
Darwin NT

Jim, have a look here at a older reddit thread.

Thanks, but I think Project Lasso is for Windows. I am on Linux, and don't change the default priorities.

You may be able to avoid the problem by running only one or two cores, but that defeats the purpose for me.
They have to fix it at the Rosetta end. LHC has managed to do so with their own Vbox wrapper.

---

Check the details tab of your individual computer(s) on this website and see if "VirtualBox VM jobs" is showing Skip. If you want VM / Python jobs, that has to say Allow

I have two computers that are worth running VM jobs on and for both of them the button "VirtualBox VM jobs" is showing "Allow"
For some strange reason they stopped getting ANY work, one has now got two ordinary R4.2 tasks ,
The pythons don't want to come out of their cages and get crunched.
It may just be a strange scheduler thing that will work itself out in time.

Or there were issues with them & they were black listed by the server.

Grant (SSSF) YOU GOT IT I am now getting Pythons again. 35 running.
The buttons work backwards {sort of}
If the button is showing "Allow" That computer is set on "skip" and will NOT get VB/Python work.
To get VB/Python work click the "Allow" button to get work again, and the button changes to "Skip" {for those that don`t want them etc}
After doing the `click and collect` I got this message on the webpage ....
------------------------------
Host updated
This host can now run VirtualBox VM jobs
This change will take effect the next time the host communicates with this project. If VM jobs cannot run due VirtualBox errors, this host will be flagged again to skip VM jobs.
_________________________
And so whoever it is [that has been blacklisted] will have to click the "Allow" button again to get tasks again to order in another takeaway of Pythons {oops sorry wrong website :), }

Jim, have a look here at a older reddit thread.

Thanks, but I think Project Lasso is for Windows. I am on Linux, and don't change the default priorities.

You may be able to avoid the problem by running only one or two cores, but that defeats the purpose for me.
They have to fix it at the Rosetta end. LHC has managed to do so with their own Vbox wrapper.

I keep losing QuChem to that problem. I am now reducing it to a single task and core from 2.
I thought python was causing troubles, that does not seem to be the case.

... Project Lasso is for Windows. I am on Linux ...

On Linux systemd slices can be used to group processes and modify/control their priorities.
The following steps can be used on a Linux system running cgroups v2.
Cgroups v1 used by older kernels have a slightly different syntax as well as different default values.


Shutdown BOINC and create/modify the systemd configuration as follows

1.
Create a slice description /etc/systemd/system/boinc.slice
Content:

[Unit]
Description=BOINC main Slice
Before=slices.target
Requires=-.slice
After=-.slice

2.
Add this to the [Service] section of your BOINC service file (usually /etc/systemd/system/boinc-client):

Slice=boinc.slice

3.
Run "systemctl daemon-reload" (or reboot) and restart BOINC.
To check whether BOINC (and all processes started by BOINC or below) is running as part of the boinc slice run "systemctl status boinc-client.service" and check for:

CGroup: /boinc.slice

The default priority for all slices on the same level is 100.
This means system(slice), user(slice) and boinc(slice) are now running at the same priority relative to each other.

This simple example (permanently) modifies the mentioned scheduler parameters:

systemctl set-property boinc.slice CPUWeight=70 CPUQuota=300% CPUQuotaPeriodSec=400ms

CPUWeight=70: reduces the relative priority of all processes running in this slice to 70
=> System processes and interactive (user) processes stay responsive even on fully loaded systems
CPUQuota=300%: limits the slice to never use more than 3 cores, even if the system has many more and even if BOINC runs many more tasks.
CPUQuotaPeriodSec=400ms: Tries to keep a process active for the given timespan (Linux default: 100ms)
=> usually better CPU cache efficiency for long running background processes

Further information can be found in the systemd manual and the kernel manual.

On Linux systemd slices can be used to group processes and modify/control their priorities.

I have tried modifying priorities on a temporary basis, but have never found any that correct the "Vm job unmanageable" problem.

This should be done by the project anyway, but thanks for the procedure.

---