1. Is this an individual project server generated limitation or is this defined locally by BOINC?
2. If I had 3 projects is the total Project 1 limit + Project 2 limit + Project 3 limit? or is it a single blanket limit?
3. Is the limit in estimated task processing hours or is the limit in number of tasks?
4. Whatever the imposed limit, what is the limit?
5. Is it GPU defined and CPU defined? or combined to both one limit fits all?

There is a client limit of 1k tasks in progress.

Some projects limit the # of tasks they'll send users based on the # of CPUs/GPUs. GPUgrid will send you 2 tasks per GPU as an example.

Thanks,
I have 48 TN-Grid Tasks and 48 Universe Tasks on one machine.
Universe @ 1% and TN @ 100%
It's been exactly that way for 27 days....and before that I wasn't checking it....
As one task is processed, one task is uploaded and one task is downloaded.
When I do a client update both TN and Universe report Reached a limit on tasks.
The machine runs pretty much TN tasks until the Universe tasks get close to deadline.
Then it's all Universe tasks for 15 Hours....complete, upload, download 48 more Universe...then wait for the Universe due date...
Cycle again..... same task numbers... 48 & 48 ...
Is 48 a limit on tasks? Surly not....
8 Processors running.
I have everything else wide open. 100% CPU's 100% of the time.
Cache is set to 5+1 days.
I'm trying to make sense of it.

What does the Event Log message say, exactly?

If it says something like

19-Feb-2019 09:20:02 [SETI@home] This computer has reached a limit on tasks in progress

then it's a limit which has been set on the project's servers - SETI@home, in this case.

Hi,
Thanks.
Is there anyway to find out what the limit value is other than contacting the project servers admins and asking the question directly?
I'd like to find out more information about the limits and how they operate.

The limits are very much in the control of the individual project.
The mechanisms employed vary from a "We'll fill your cache to the limits" to "We will send you one task for every task you return", to "We will send you x tasks per day and that's it", and some projects don't appear to have any limits at all, and don't respect your cache or work being done on other projects...

The limits are very much in the control of the individual project.
The mechanisms employed vary from a "We'll fill your cache to the limits" to "We will send you one task for every task you return", to "We will send you x tasks per day and that's it", and some projects don't appear to have any limits at all, and don't respect your cache or work being done on other projects...

Yes, I agree.... that is what I have realized as well.

CPDN will send enough tasks to fill up the cache up to the limit set in BOINC. However it won't send more than one/cpu/day if you crash them. Serial crashers get this et to zero and an email asking them to let the project know when they have sorted out the problem and they can begin crunching again. (Most common reason is missing 32bit libs on Linux machines.)

If a project sets it's MAX_TASK_LIMIT to 48 and I have a machine with 10 processors that processes a task in 4 hours and a cache size to 6 days then it's 48 tasks*4 hours/10 processors = 19.2 hours CPU processing time, which represents an actual cache size of .8 days....
As CPU/GPU Cores/Threads increase in number along with CPU/GPU increased processing speeds the local hosts "Cache Size" becomes more and more irrelevant.
Such as in the case of a 32 core processor or 64 core processor XEON.... a MAX_TASK_LIMIT of 48 will barely feed a 32 core and won't feed a 64 efficiently.

But an average 10 core machine is barely cached at all at 48 tasks at 4 hours per task.
If processing time is 15 hours then actual cache increases to 3 days.....
Either way the host machine is constantly asking for work unless the local host cache size is set to 2 + 1.....

But an average 10 core machine is barely cached at all at 48 tasks at 4 hours per task.

CPDN tasks are notoriously long though times are mostly measured in days or possibly weeks now as compared with when I started crunching for them and they could last over six months!

DHEP is the same way....
It's outside the host cache settings.

If a project sets it's MAX_TASK_LIMIT to 48 and I have a machine with 10 processors that processes a task in 4 hours and a cache size to 6 days then it's 48 tasks*4 hours/10 processors = 19.2 hours CPU processing time, which represents an actual cache size of .8 days....
As CPU/GPU Cores/Threads increase in number along with CPU/GPU increased processing speeds the local hosts "Cache Size" becomes more and more irrelevant.
Such as in the case of a 32 core processor or 64 core processor XEON.... a MAX_TASK_LIMIT of 48 will barely feed a 32 core and won't feed a 64 efficiently.

But an average 10 core machine is barely cached at all at 48 tasks at 4 hours per task.
If processing time is 15 hours then actual cache increases to 3 days.....
Either way the host machine is constantly asking for work unless the local host cache size is set to 2 + 1.....

Many projects will limit the # of tasks they distribute to a host based of the # of cores reported by the client. Some are as low as 4x, others 10x, while some projects do not limit and you can end up with 1k tasks.