The regular Rosetta tasks also reserve 8gb of ram per task

Complete and utter rubbish.

Stop making things up.

how much the Virtual Memory Size is and the Working set size is, you care about the one that shows the most memory.

No you don't.
Virtual memory is just that- virtual memory. It is used if there isn't enough physical RAM. The Working Set size is the one that matters.

If the amount of Virtual Memory required becomes an issue, then you've got a much bigger problem with your system as a whole due to lack of free disk space than some value reported for a particular Rosetta Task.

---

Grant
Darwin NT

It is a confirmed BOINC (not Rosetta) bug with excessive workunit fetch for a project if <max_concurrent> setting is used.

It was identified about year ago or so.
One of the latest bug reports to BOINC developer: https://github.com/BOINC/boinc/issues/4322

And finally a patch to this problem is in work now: https://github.com/BOINC/boinc/pull/4592
It will be included in one of the future BOINC releases.

For now there are few workarounds until new fixed version of BOINC available:
1 - avoid using <max_concurrent> setting completely
OR
2 - set work cache size to a really low values
OR
3 - use R@H with other projects with stable WUs supply and WITHOUT <max_concurrent> setting applied to this "spare" projects (only to R@H)

Because bug itself is a wrong calculation of amount of work BOINC already have in queue for projects limited by <max_concurrent> setting.
It just count only up to <max_concurrent> number of tasks in queue and ignores the rest. So calculated work queue size does not increase no matter how many tasks BOINC has already loaded for a such project. And falls into an endless loop of getting new work.

And finally a patch to this problem is in work now: https://github.com/BOINC/boinc/pull/4592
It will be included in one of the future BOINC releases.

Glad to see there might finally be a fix for this issue.

---

Grant
Darwin NT

Thanks for this input Mad Max.

I may give it a try, next year when FB is over :)

---

You can get around that by adding the word project_ to the max concurrent.
I have been using this for a few days now and it works perfect.
[project_max_concurrent] N [/project_max_concurrent]

The regular Rosetta tasks also reserve 8gb of ram per task

Complete and utter rubbish.

Stop making things up.

how much the Virtual Memory Size is and the Working set size is, you care about the one that shows the most memory.

No you don't.
Virtual memory is just that- virtual memory. It is used if there isn't enough physical RAM. The Working Set size is the one that matters.

If the amount of Virtual Memory required becomes an issue, then you've got a much bigger problem with your system as a whole due to lack of free disk space than some value reported for a particular Rosetta Task.

Grant, hes not that far off. 7629.39 physical per task and 103.13 virtual (cages tasks)

He said it about regular (non Python/virtual box) task. Regular R@H tasks RAM usage lies in 0.7-3 Gb range for almost all tasks (for >95% of tasks) and in 0.7-1.5 Gb usually (for >70%).
So it is very far from the 8 GB per tasks.

If I can read github correctly, it is said that this patch will be published in boinc 7.20.0 ??

---

Yes, it already included in BOINC ver 7.20.0 (and later).

But v. 7.20 itself is not finished yet.