project? I have never seen that before.
Most of us tried to use max_concurrent and then got buried in tons of tasks we could never complete by their deadlines.


Project_max_current will limit the total number of work units running for all projects.

But either one of them can cause the problem of excessive downloads.

Well, I use only the <project_max_concurrent> not <max_concurrent>,
and then only in the app_config.xml file in the

/var/lib/boinc/projects/boinc.bakerlab.org_rosetta directory.

[/var/lib/boinc/projects/boinc.bakerlab.org_rosetta]$ cat app_config.xml 
<app_config>
   <project_max_concurrent>3</project_max_concurrent>
</app_config>

I use similar app_config.xml files in the project directories for my other projects as well (with different limits).

localhost:jeandavid8[/var/lib/boinc/projects]$ ls -l

 16384 Nov 30 06:20 boinc.bakerlab.org_rosetta
 12288 Nov 29 16:53 climateprediction.net
 24576 Nov 29 23:13 universeathome.pl_universe
 40960 Nov 30 13:15 www.worldcommunitygrid.org

I am running
boinc-client-7.16.11-3.el8.x86_64
that is the most up-to-date one for this machine and OS. The OS is up-to date as well.

Computer 5910575

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.5 (Ootpa) [4.18.0-348.2.1.el8_5.x86_64|libc 2.28 (GNU libc)]
BOINC version 	7.16.11
Memory 	         63902.16 MB
Cache 	            16896 KB
Swap space 	    15992 MB
Total disk space   117.21 GB
Free Disk Space     92.03 GB

---

Pythons are back and I received 5 on my 8 GB laptop which previously received none.

---

Is there a dummies page with a simple explantion to set this up?

With BOINC, it only gets worse.
https://boinc.berkeley.edu/wiki/Client_configuration#Options

I've seen something else elsewhere. I'll look that up this weekend.

project? I have never seen that before.
Most of us tried to use max_concurrent and then got buried in tons of tasks we could never complete by their deadlines.


Project_max_current will limit the total number of work units running for all projects.

But either one of them can cause the problem of excessive downloads.

Well, I use only the <project_max_concurrent> not <max_concurrent>,
and then only in the app_config.xml file in the

/var/lib/boinc/projects/boinc.bakerlab.org_rosetta directory.

[/var/lib/boinc/projects/boinc.bakerlab.org_rosetta]$ cat app_config.xml 
<app_config>
   <project_max_concurrent>3</project_max_concurrent>
</app_config>

I use similar app_config.xml files in the project directories for my other projects as well (with different limits).

localhost:jeandavid8[/var/lib/boinc/projects]$ ls -l

 16384 Nov 30 06:20 boinc.bakerlab.org_rosetta
 12288 Nov 29 16:53 climateprediction.net
 24576 Nov 29 23:13 universeathome.pl_universe
 40960 Nov 30 13:15 www.worldcommunitygrid.org

I am running
boinc-client-7.16.11-3.el8.x86_64
that is the most up-to-date one for this machine and OS. The OS is up-to date as well.

Computer 5910575

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.5 (Ootpa) [4.18.0-348.2.1.el8_5.x86_64|libc 2.28 (GNU libc)]
BOINC version 	7.16.11
Memory 	         63902.16 MB
Cache 	            16896 KB
Swap space 	    15992 MB
Total disk space   117.21 GB
Free Disk Space     92.03 GB

So? How's that working out on Python? That might be the solution to limit them.

Pythons are back and I received 5 on my 8 GB laptop which previously received none.

Looks like I can run 2 Pythons plus 3 MCM tasks. So 3 threads are idle.

---

PYTHON MINI ARE IN
names like . aagb-AGLY......
`task` - `properties` gives
working set size 2.79GB
virtual memory size 99MB
progressing @ 12.6% per hour
that's a lot better :)

edit
Hellow Falconet, we were typing at the same time :)
another edit
got some cosmology@hum docker tasks to finish off then find out how many Python mini fits into 32GB
yet another idiot, oops, I ment edit
front page news - Total queued jobs: 2,197,433

Had to reboot it coz it cant handle 15 , changed `use cpu` settings and got 11 running so far
but its thrashing the disk when it starts them
only 20GB memory in use
100GB disk space in use by rosetta

Well, I use only the <project_max_concurrent> not <max_concurrent>,
and then only in the app_config.xml file in the

/var/lib/boinc/projects/boinc.bakerlab.org_rosetta directory.

[/var/lib/boinc/projects/boinc.bakerlab.org_rosetta]$ cat app_config.xml
<app_config>
<project_max_concurrent>3</project_max_concurrent>
</app_config>

So? How's that working out on Python? That might be the solution to limit them.

I have no idea.

Mon 29 Nov 2021 01:31:22 AM EST | Rosetta@home | Message from server: VirtualBox is not installed

I do no have VirtualBox, so I cannot run them.

---

Well, I use only the <project_max_concurrent> not <max_concurrent>,
and then only in the app_config.xml file in the

/var/lib/boinc/projects/boinc.bakerlab.org_rosetta directory.

[/var/lib/boinc/projects/boinc.bakerlab.org_rosetta]$ cat app_config.xml
<app_config>
<project_max_concurrent>3</project_max_concurrent>
</app_config>

So? How's that working out on Python? That might be the solution to limit them.

I have no idea.

Mon 29 Nov 2021 01:31:22 AM EST | Rosetta@home | Message from server: VirtualBox is not installed

I do no have VirtualBox, so I cannot run them.

hmm...ok...well maybe after they load up the project again I will try that.

Well I gave the confuzer a while to get its act together with 11 wu, then tried to increase it to twelve cpu`s
it don`t want to play, BM put it on hold with ` waiting for memory` [20GB in actual use]
So that's my lot with a 16 cpu opteron and 32GB mem, using about 75< 80% cpu
a lot better than the 4 wu it ran with big pythons.

Now then what can I meddle with next . . . .
How about going to `vbox64_mt` and setting the default cpu count to two and then half the default run time
that would offset the memory use and use more cpu`s , hmm ;)

Well I gave the confuzer a while to get its act together with 11, then tried to increase it to twelve cpu`s
it don`t want to play, BM put it on hold with ` waiting for memory` [20GB in actual use]
So that's my lot with 16 cpu opteron and 32GB mem, using about 75< 80% cpu
a lot better than the 4 wu it ran with big pythons.

Now then what can I meddle with next . . . .
How about going to `vbox64_mt` and setting the default cpu count to two and then half the default run time
that would offset the memory use and use more cpu`s , hmm ;)

You'd better check if Oracle provides vbox64_mt and whether the Python tasks are able to use it before doing much with that.

The Python tasks now only reserve 2.79GB of memory each, at least for Windows 10, so the project staff HAS found a way to control the amount of memory reserved.

The Python tasks now only reserve 2.79GB of memory each, at least for Windows 10, so the project staff HAS found a way to control the amount of memory reserved.

And if they bring it down to 1.5GB or so then everything should be OK.

Would be nice if we were to get some more Rosetta 4.20 Tasks as well.

---

Grant
Darwin NT

The created VMs still have the same Hard Disk and RAM set up as before. 8Gb HD and 6Gb RAM.
All tasks I had running had to be aborted. They weren't using any cpu cycles.

Is anyone successfully completing one?

The created VMs still have the same Hard Disk and RAM set up as before. 8Gb HD and 6Gb RAM.
All tasks I had running had to be aborted. They weren't using any cpu cycles.

Is anyone successfully completing one?

Mine are saying 2.79 GB of RAM and using barely over 56 MB each.
I've completed 4 so far on my laptop.


I see you got a few done. OThers were aborted. If they weren't using CPU cycles, it's possible they were some of those that hang for hours and hours.

---

What Boinc reports and what the VM is created with is two different things. I get about the same results as you looking at the Boinc task properties.
All the successful tasks were the previous Python versions. Started with "boinc_cages_IL_"

I haven't got a single, newer one to run yet. they all hang and when I call up the VM's screen the last line is
"Intel MKL FATAL ERROR: Error on loading function mkl_lapack_ps_mc3_dsytrf_l_small."

If you call up Virtual box and look at a VM, is you last line like that on the monitor? You just go to Machine - Detach GUI to close it afterwards.

I see VB reports 6144 MB of base memory.
No, I don't have that line when I open the VM on either of the 2 Pythons that seem to be running fine.

---

I've got one here that's saying 6GB, but also one that has 10200MB! And 20GB of disk space...

---

I'm still running 2 Pythons and Rosetta is using 24 GB of my SSD.

---

snip...
Now then what can I meddle with next . . . .
How about going to `vbox64_mt` and setting the default cpu count to two and then half the default run time
that would offset the memory use and use more cpu`s , hmm ;)

You'd better check if Oracle provides vbox64_mt and whether the Python tasks are able to use it before doing much with that.
The Python tasks now only reserve 2.79GB of memory each, at least for Windows 10, so the project staff HAS found a way to control the amount of memory reserved.

cosmology@home has been using `vbox64_mt` for a few years on its vbox work

I see there are still a lot of big Python _1 tasks in the pipeline, resends that will take a while to clean up, that still demand big memory, and stop the python mini`s running

snip...
Now then what can I meddle with next . . . .
How about going to `vbox64_mt` and setting the default cpu count to two and then half the default run time
that would offset the memory use and use more cpu`s , hmm ;)

You'd better check if Oracle provides vbox64_mt and whether the Python tasks are able to use it before doing much with that.
The Python tasks now only reserve 2.79GB of memory each, at least for Windows 10, so the project staff HAS found a way to control the amount of memory reserved.

cosmology@home has been using `vbox64_mt` for a few years on its vbox work

I see there are still a lot of big Python _1 tasks in the pipeline, resends that will take a while to clean up, that still demand big memory, and stop the python mini`s running

Good. The other problem is whether the Rosetta python tasks are written to know how to use it.