I find this odd, 9,000+ pythons and 24,000+ 4.2 tasks, yet all I get is 4.2
I got python when it first started.

I reset the project, but still no python.

Any ideas as to why the drought on python now, when I had them in the past?
Did something change in the requirements?

Any ideas as to why the drought on python now, when I had them in the past?
Did something change in the requirements?

Is virtualization enabled in bios?
What's the log of boinc Manager? There is something like:

 No WSL found.
VirtualBox version: 6.1.26

P.S.
I have the same problem on my notebook and i cannot find the solution

---

I find this odd, 9,000+ pythons and 24,000+ 4.2 tasks, yet all I get is 4.2
I got python when it first started.

I reset the project, but still no python.

Any ideas as to why the drought on python now, when I had them in the past?
Did something change in the requirements?

The only thing that worked for me was to keep aborting all the regular Rosetta tasks and finally Rosetta would start sending me some Python tasks, I now have over half a dozen on each of my pc's and no regular Rosetta tasks.

DAMN I wish they would at least TRY a preferences switch and see what happens, they can always turn it back off next week!!!!

DAMN I wish they would at least TRY a preferences switch and see what happens, they can always turn it back off next week!!!!

It might be a lot of work to implement.

---

DAMN I wish they would at least TRY a preferences switch and see what happens, they can always turn it back off next week!!!!

It might be a lot of work to implement.

Mmmm, no.
It's very easy on boinc server to implement 2 different apps

---

Any ideas as to why the drought on python now, when I had them in the past?
Did something change in the requirements?

Is virtualization enabled in bios?
What's the log of boinc Manager? There is something like:

 No WSL found.
VirtualBox version: 6.1.26

P.S.
I have the same problem on my notebook and i cannot find the solution

I run LHC ATLAS. That is a Vbox project.

DAMN I wish they would at least TRY a preferences switch and see what happens, they can always turn it back off next week!!!!

It might be a lot of work to implement.

Mmmm, no.
It's very easy on boinc server to implement 2 different apps

Because Python is new, they haven't bothered updating their webpage to reflect that as a soul project choice or a opt out choice. They are always a bit slow to change anything.
I think they figure we will find a way to opt out or to do like you do and force the server to send other work via aborts and such. We always find a way to get our machines to do what they need to do with little or no input from the Baker Lab.

And yes it is easy to add the option to add or subtract or run solo the Python work. WCG runs how many projects under it's server? 5 or more? And you can opt in or out of all of them, plus the usual CPU/GPU preferences. Same with Einstein, you can opt in or out of projects and CPU/GPU.

Not sure what Baker Lab's excuse is, other than they don't want to change anything.

My only real problem with the pythons is the "virtualbox unmanageable" error that frequently occurs.

I don't think we can do anything about it on our end. They have to fix it on their end.
There was a post somewhere that it is due to changes made by Oracle on virtualbox, and the project needs a new wrapper. That is not our thing.

---

DAMN I wish they would at least TRY a preferences switch and see what happens, they can always turn it back off next week!!!!

It might be a lot of work to implement.

Mmmm, no.
It's very easy on boinc server to implement 2 different apps

Because Python is new, they haven't bothered updating their webpage to reflect that as a soul project choice or a opt out choice. They are always a bit slow to change anything.
I think they figure we will find a way to opt out or to do like you do and force the server to send other work via aborts and such. We always find a way to get our machines to do what they need to do with little or no input from the Baker Lab.

And yes it is easy to add the option to add or subtract or run solo the Python work. WCG runs how many projects under it's server? 5 or more? And you can opt in or out of all of them, plus the usual CPU/GPU preferences. Same with Einstein, you can opt in or out of projects and CPU/GPU.

Not sure what Baker Lab's excuse is, other than they don't want to change anything.

And PrimeGrid runs over a dozen different sub-projects all at the same time with no problems, they manage their priorities thru task availability, ie a push over there and they wind up the Server to produce alot of those and fewer of the others kinds. They also use Challenges to get users to hyper focus on a particular type of task for x amount of time.

My only real problem with the pythons is the "virtualbox unmanageable" error that frequently occurs.

I don't think we can do anything about it on our end. They have to fix it on their end.
There was a post somewhere that it is due to changes made by Oracle on virtualbox, and the project needs a new wrapper. That is not our thing.

Are you giving it at least 8gb of ram? If not it may crash because the tasks are STILL asking for that much ram but only using about 60meg per task on my Windows11 laptop when actually running.

Are you giving it at least 8gb of ram? If not it may crash because the tasks are STILL asking for that much ram but only using about 60meg per task on my Windows11 laptop when actually running.

I have 64 GB on a Ryzen 3900X, and they stop anyway.

That happens on almost all VirtualBox projects. Only LHC does it right, because they use an updated wrapper. I don't know if it was from Oracle, or their own thing.
They mentioned it on some forum a while ago. If you search for "virtualbox unmanageable", you might find it. It was a comment directed to Dave Anderson no less, but I don't know if he saw it.
I think he mentioned that it may take an update to BOINC to fix the other projects.

PS - Are you saying that you don't have the problem?

---

Are you giving it at least 8gb of ram? If not it may crash because the tasks are STILL asking for that much ram but only using about 60meg per task on my Windows11 laptop when actually running.

I have 64 GB on a Ryzen 3900X, and they stop anyway.

That happens on almost all VirtualBox projects. Only LHC does it right, because they use an updated wrapper. I don't know if it was from Oracle, or their own thing.
They mentioned it on some forum a while ago. If you search for "virtualbox unmanageable", you might find it. It was a comment directed to Dave Anderson no less, but I don't know if he saw it.
I think he mentioned that it may take an update to BOINC to fix the other projects.

PS - Are you saying that you don't have the problem?

I do not have the problem on my AMD Ryzen 7 4800 model laptop with 16gb of ram but am only running 1 task at a time. I AM having the problem you mentioned on my MacBook Pro with 16gb of ram but it could be trying to run multiple units at once so for now it's on another project. My MacPro desktop with 24gb of ram running 2 tasks at once seems to be doing just fine as well. I do not set any variables for Virtual Box when I install it on my computers, I just leave it set at the defaults and Boinc handles the rest.

OK, that is useful. It may happen only when running multiple work units (or at least more than two).
In that case, smaller memory may be better. You can't use an app_config to limit the number of work units until they get the download bug fixed.

I can run Rosetta in a second BOINC instance and limit it to one or two work units at a time, but that affects both the pythons and the non-pythons.
They need to give us some way to select them.

Thanks.

---

OK, that is useful. It may happen only when running multiple work units (or at least more than two).
In that case, smaller memory may be better. You can't use an app_config to limit the number of work units until they get the download bug fixed.

I can run Rosetta in a second BOINC instance and limit it to one or two work units at a time, but that affects both the pythons and the non-pythons.
They need to give us some way to select them.

Thanks.

You say that you *can’t* use app_config to limit the number of work units but I’ve been doing so for a couple of years with zero problems.

Each of my projects has :-

<app_config>
<project_max_concurrent>N</project_max_concurrent>
</app_config>


and it limits the processing as required with no runaway downloads.

You say that you *can’t* use app_config to limit the number of work units but I’ve been doing so for a couple of years with zero problems.

Each of my projects has :-

<app_config>
<project_max_concurrent>N</project_max_concurrent>
</app_config>

and it limits the processing as required with no runaway downloads.

Have you tried that on Rosetta with multiple pythons running at once, and with the regular Rosettas running?

To limit the pythons, you would have to use

<app>
<name>rosetta_python_projects</name>
<max_concurrent>X</max_concurrent>
</app>

Then, along with the regular Rosettas, it gets confused. I have seen it on several other projects, or combinations of projects, where different types of work units are present.
It might work on single types of work units, but you don't need it so much there, since you can just limit the number of cores running.

And it is rather sporadic. You may not have encountered it yet, but that is no guarantee of the future.
It did not happen in the older BOINC versions either, but it started a couple of years ago for me.

You can read about it on the LHC forum, and the cited bug report:
https://lhcathome.cern.ch/lhcathome/forum_thread.php?id=5726
https://github.com/BOINC/boinc/issues/4322

---

You say that you *can’t* use app_config to limit the number of work units but I’ve been doing so for a couple of years with zero problems.

If you check out several of the other threads that Greg_BE has posted to, you would see that using max_concurrent has caused huge amounts of problems in the past- basically the Scheduler allocates 100s (or more) Tasks, when only a few are actually needed.
While it might not cause problems with your systems & projects, it does with Gre_BE here at Rosetta on one of his systems.
As jim1348 posted, he has also had similar issues, when using project_max_concurrent.

There is a bug (rare as it is) with max_concurrent/project_max_concurrent that has yet to be resolved.

---

Grant
Darwin NT

You say that you *can’t* use app_config to limit the number of work units but I’ve been doing so for a couple of years with zero problems.

If you check out several of the other threads that Greg_BE has posted to, you would see that using max_concurrent has caused huge amounts of problems in the past- basically the Scheduler allocates 100s (or more) Tasks, when only a few are actually needed.
While it might not cause problems with your systems & projects, it does with Gre_BE here at Rosetta on one of his systems.
As jim1348 posted, he has also had similar issues, when using project_max_concurrent.

There is a bug (rare as it is) with max_concurrent/project_max_concurrent that has yet to be resolved.

I have obviously seen the bug reports you reference and they usually take the form don’t do it, it always causes problems.

For the sake of balance and to inform those tying to track down the bug I wanted to register the fact that, in some circumstances, it works ok and is stable.

That happens on almost all VirtualBox projects. Only LHC does it right, because they use an updated wrapper.

Uh? Which version of wrapper are we using on R@H??
The latest official wrapper from boinc developers is 26203 (September 2020)

---

Uh? Which version of wrapper are we using on R@H??
The latest official wrapper from boinc developers is 26203 (September 2020)

Don't know. LHC may have rolled their own.

---

Don't know. LHC may have rolled their own.

From LHC folder in C:ProgramData seems that the LHC wrapper is 26198ab7.
I don't know if it is official or personalized

---