yes app config works but you cannot install it on machines over account manager

seems admin does not care their project fails WUs from others. Anyway i stopped crunching Sidock

---

I crunch for Ukraine

yes app config works but you cannot install it on machines over account manager



I use BOINCSTATS and use the APP_CONFIG with no problems

Not sure where an account manager comes into it, since there is the option to "read config files" that is still active

yes app config works but you cannot install it on machines over account manager



I use BOINCSTATS and use the APP_CONFIG with no problems

Not sure where an account manager comes into it, since there is the option to "read config files" that is still active

I just opened BAM! and I dont see such option there to edit app_config on a host. Where is it located ?

---

I crunch for Ukraine

This is a local setting and you have to configure it on each host.

Go to your BOINC data directory, inside projects/www.sidock.si_sidock folder, create the app_config.xml with content shown above. Once done, go to BOINC manager -> Options -> Read config files to read the new config.

seems admin does not care their project fails WUs from others. Anyway i stopped crunching Sidock

I don't think it's that admin doesn't care. hoarfrost clearly responds to posts often. However, monitoring random hosts that one has no information or control isn't exactly easy task. BOINC is designed to tolerate such hosts, and those WUs simply get re-issue to other hosts. So long as they don't fail in a row exceeding the limit, the project gets their results.

As I explained, because Sidock has very long tasks, this puts all other projects at risk of missing deadlines and missing credits

I'm curious what's your buffer setting (that "store at least XX days of work")? BOINC client really shouldn't fetch too many work. Setting that to a very low number like 0.001 should prevent excessive work from being fetched even with initial estimate and without project_max_concurrent setting.

Btw, I saw you have one client on v7.16. Make sure you upgrade to at least 7.20 before doing that app_config.xml. There was actually a bug related to the project_max_concurrent config that could result in excessive fetch of work in older versions.

Note that the <max_concurrent> tag in the app_config.xml file sets the maximum number of tasks of a specific application to run at a given time. It does not control the work cache size, meaning if you set the max_concurrent to "2" say, it will download tasks to fill whatever cache size and the cpu thread to use that you specified. It will only run 2 tasks irrespective of your cache size. However there is a bug in the boinc manager (not sure what version that is) that could potentially load more tasks that you need and override the cache size. Just fyi.

Actually, this setting do AFFECTS the work cache size. Just not directly in the sense that BOINC can not download no more than the number of tasks specified in this parameter. But so that no more is downloaded than can be calculated in the time specified in the cache size settings with the number of threads specified in the max_concurrent setting.
In a simple example. Source data:
the machine has 6 cores/12 threads
and has a cache setting = 2 days
1 task takes an average of 16 hours
(note: the average computation time per task is taken for this particular machine - from the client's local statistics, not from server).

Without additional restrictions, BOINC can download up to 36 tasks from one project to such a machine: 2*24/16*12 = 36
And thus fill the entire cache with only tasks for this one project. For example, this may happen if at some point there are no available tasks in other connected projects.

Now if, all other things being equal, we add a setting to the same machine
<project_max_concurrent>4</project_max_concurrent>

Then BOINC will not download more than 12 tasks to the cache: 2*24/16*4 = 12

P.S.
Yes, there was a critical bug with the operation of this mechanism in older versions of BOINC (lower than 7.20.xx). Because of which, with the max_concurrent option active, downloading tasks to the cache could happen in huge quantities (up to 1000 tasks from one project, regardless of the specified cache size).
But this bug has been already fixed about 2 years ago in BOINC clients version 7.20.0: https://boinc.berkeley.edu/wiki/Release_Notes

Changes in 7.20.0
.....
Client: fix work-fetch logic when max concurrent limits are used

BOINC versions starting from >= 7.20 should work correctly from now on, according to the logic described at the beginning of the post: at the same time limiting both the number of simultaneously running tasks and the number of tasks in the working cache.