Windows seems to have some limit, depending bit size and whether its home or pro or enterprise. IIRC, Linux had a limit, based on the bit size of the OS. Other than that, BOINC (has/had?) a limit of 200 job slots per client instance. If more are used, no further task can be started until previous job finishes. This ignores memory constraints, physical or serviceable by the OS.

Sometimes clients do not recognize the full core count, so a manual cc_config setting needs to force the hand. That problem seems to often arise above 32 threads. Occasionally see a despair post of a member who's got some monster 48-64-96 thread system, and not getting the client to start more than N jobs, at which point the option <ncpus>N</ncpus> will work for most all cases.

Yes, that is the caching side, but started jobs is FAIK ltd to 200 and throws an error when a job is started without a free slot in the range 0-199 (a result of a project that not properly clears after completion. Not so long ago we had such a reported issue on these forums, or maybe it was Berkeley's).

Saw this morning a new garbage disposal tag is being implemented. If there is no task on the client related to a specific science app, all related to that app will be removed. Not so sure about being a proponent, particular when work is intermittent AND the one-time parts of a science are big or being on the meter.

I think you misunderstood something or I do^^

The idea is to remove the files of an deprecated app when no task of this app is in progress anymore.

https://github.com/BOINC/boinc/issues/2212

If one looks at the posted issue link and the time line, one sees that Juha also put the finger on the same sore spot I commented on, so an actual project check is being added which apps are still maintained by the project. Now that throws a reverse spanner, since WCG keeps old apps on, just in case a client keeps asking for an old apps files... Is this a Catch 22? Only a project detach removes all trace of an old apps elements presently, though seem to remember such a mechanism of removing apps for which there was no task left on the client was already in place, but then at some point got disabled for the same concerned reason (would have to dig these forums, but am fairly sure).

YES it's a continuation of OT

There's also the 70 per-active-thread buffer limit (used to be 35), but what the active overruling total limit is I've not seen as having been upgraded. Your message log would tell... just increase your buffer setting and see if you can hit the new wall.