Yes, the client and project max allowed is 1000 tasks. That is the default BOINC client and server limit unless overridden by the project admins or running a custom client.
That makes a lot of sense.
to get a bit detailed about it, the point of limitation is on requesting more work. It won't request more if you already have 1000 aboard.
But if you have 998 aboard and request a bunch, you can get dozens of tasks above the 1000 limit. The very next request, typically about a minute later, will get denied.
So if folks spotting this comment have seen somewhat over 1000, that scenario is probably why. Buffer limitations mean you are not likely to have seen more than a few score over 1000, even this way.
Of course, one other way is to compile your own private version with the limitation adjusted, but I suspect people considering doing that to be a pretty small population.
really, really minor aside: Years ago a surprising amount of important aerospace code was written in Jovial, which apparently stands for "Jules' Own Version of the Intenational Algorithmic Language"
Of course, one other way is to compile your own private version with the limitation adjusted, but I suspect people considering doing that to be a pretty small population.
GPU Users Group. Guilty as charged. But yes we are only about 20 active members.
I had exactly this problem back in January when I upgraded from 7.14.2 to 7.16.16 and overnight had downloaded more than 1000 tasks. (Yes, using <project_max_concurrent> config parameter.) My minimal system can do 100 (GPU) tasks per day; so, in principle, would not reach the deadlines -- but... I'm running a mix of CPU & GPU applications and the CPU tasks can't get done by their deadlines.
My solution (work-around) was to revert (downgrade) to 7.14.2, which does not have the relevant max_concurrent bug and all is running smoothly. Presumably there were enhancements in 7.16 that I don't have but, so far, I don't see any game breakers. Someday, when comments in this forum indicate that the bug is fixed, I'll make the upgrade to 7.20.x or 7.22.x - or whatever version.
(Yes, mixing CPU & GPU tasks does not play smoothly in the buffer manager, trying its best to find an "average" task execution time between wildly different CPU & GPU values, but just set the buffer parameters really small (I use 0.3 + 0.1 days) and there will not be any deadline failures.)
to get a bit detailed about it, the point of limitation is on requesting more work. It won't request more if you already have 1000 aboard.
But if you have 998 aboard and request a bunch, you can get dozens of tasks above the 1000 limit. The very next request, typically about a minute later, will get denied.
So if folks spotting this comment have seen somewhat over 1000, that scenario is probably why. Buffer limitations mean you are not likely to have seen more than a few score over 1000, even this way.
Of course, one other way is to compile your own private version with the limitation adjusted, but I suspect people considering doing that to be a pretty small population.
That would be a nice thing to make configurable.
Sometimes I think it would be nice to be able to write a script in javascript or some such that would control the task fetching. But that would probably be overkill.
Neal Burns wrote: Keith
)
to get a bit detailed about it, the point of limitation is on requesting more work. It won't request more if you already have 1000 aboard.
But if you have 998 aboard and request a bunch, you can get dozens of tasks above the 1000 limit. The very next request, typically about a minute later, will get denied.
So if folks spotting this comment have seen somewhat over 1000, that scenario is probably why. Buffer limitations mean you are not likely to have seen more than a few score over 1000, even this way.
Of course, one other way is to compile your own private version with the limitation adjusted, but I suspect people considering doing that to be a pretty small population.
really, really minor aside: Years ago a surprising amount of important aerospace code was written in Jovial, which apparently stands for "Jules' Own Version of the Intenational Algorithmic Language"
archae86 wrote: Of course,
)
GPU Users Group. Guilty as charged. But yes we are only about 20 active members.
I had exactly this problem
)
I had exactly this problem back in January when I upgraded from 7.14.2 to 7.16.16 and overnight had downloaded more than 1000 tasks. (Yes, using <project_max_concurrent> config parameter.) My minimal system can do 100 (GPU) tasks per day; so, in principle, would not reach the deadlines -- but... I'm running a mix of CPU & GPU applications and the CPU tasks can't get done by their deadlines.
My solution (work-around) was to revert (downgrade) to 7.14.2, which does not have the relevant max_concurrent bug and all is running smoothly. Presumably there were enhancements in 7.16 that I don't have but, so far, I don't see any game breakers. Someday, when comments in this forum indicate that the bug is fixed, I'll make the upgrade to 7.20.x or 7.22.x - or whatever version.
(Yes, mixing CPU & GPU tasks does not play smoothly in the buffer manager, trying its best to find an "average" task execution time between wildly different CPU & GPU values, but just set the buffer parameters really small (I use 0.3 + 0.1 days) and there will not be any deadline failures.)
If you build the client from
)
If you build the client from the current Master branch it has the project max concurrent bugfix.
archae86 wrote: to get a bit
)
That would be a nice thing to make configurable.
Sometimes I think it would be nice to be able to write a script in javascript or some such that would control the task fetching. But that would probably be overkill.
Don’t even need JavaScript.
)
Don’t even need JavaScript. You could easily write something in bash and using the boinccmd tool.
basic logic:
-set maximum and minimum number of task values.
-fetch/read number of tasks on the host (maybe using boinccmd and a loop with a count variable to get the total)
-if #tasks is less than minimum, use boinccmd to allow new work. Initiate a schedule request (project --update in boinccmd)
-if #tasks is between min and max, do nothing.
-if #tasks is greater than maximum, use boinccmd to set no new tasks.
then just loop it on some interval that’s appropriate, like every 5 mins or something
_________________________________________________________________________
Ian&Steve C. wrote: Don’t
)
Thanks for the tip. I was meaning to look at the boinccmd tool.
I set "allow new work" again
)
I set "allow new work" again and I captured these logs. This might indicate the problem: For long stretches it fetches 1 task every 60 seconds.