No work available (reached daily quota)

Burned
Burned
Joined: 25 Jun 21
Posts: 24
Credit: 43,198,649
RAC: 3

Apparently fetching new work

Apparently fetching new work is just an artifact of hitting "Update" on the BOINC manager project tab.  I'll explore app_config as a permanent solution.

Burned
Burned
Joined: 25 Jun 21
Posts: 24
Credit: 43,198,649
RAC: 3

This works.  I created an

This works.  I created an app_config.xml file in my BOINC\projects\einstein folder containing

<app_config>
   <project_max_concurrent>8</project_max_concurrent>
</app_config>

This successfully limits concurrent tasks to eight regardless of other usage limits.  The usage limits that are used in the quota computation e.g. "use at most x% of cpus" can then be set higher which in turn increases the quota.    

Gary Roberts
Gary Roberts
Moderator
Joined: 9 Feb 05
Posts: 5,495
Credit: 65,858,730,876
RAC: 54,357,955

Good to know it

Good to know it works!

That's the easiest and least intrusive way of working around the problem for your situation.

 

Cheers,
Gary.

archae86
archae86
Joined: 6 Dec 05
Posts: 3,021
Credit: 5,000,467,095
RAC: 3,001,458

Thank you so much for

Thank you so much for reporting back your observations.  That makes it much more likely someone else can go to school on your experience.

Ian&Steve C.
Ian&Steve C.
Joined: 19 Jan 20
Posts: 916
Credit: 6,750,096,494
RAC: 21,828,404

yes thanks for reporting

yes thanks for reporting back. glad my suggestion to use project_max_concurrent worked for you.

just keep an eye on work fetch. I think there was a bug related to use of this parameter that caused work fetch to not work properly (it would fetch too much IIRC). I don't know if that was ever fixed in BOINC code. I think Richard Haselgrove would know. he was involved with the bug report on that one i think. 

_____________________________________________

Burned
Burned
Joined: 25 Jun 21
Posts: 24
Credit: 43,198,649
RAC: 3

Thanks, I will watch work

Thanks, I will watch work fetch.  This is the quota computation that I noticed when I implemented the app_config change.  My cc_config is set to 48 (this is now unnecessarily high).  My computing preference option is set to 20% of CPU's.  That should round down to 9 cpus.  (9*32) + (1*256) = 544.  Sure enough, logfile says "(reached daily quota of 544 tasks)".  It just occurred to me that I need to make sure that I am not just getting more CPU tasks.  Its GPU tasks that I run short of. 

Gary Roberts
Gary Roberts
Moderator
Joined: 9 Feb 05
Posts: 5,495
Credit: 65,858,730,876
RAC: 54,357,955

Burned wrote:My computing

Burned wrote:
My computing preference option is set to 20% of CPU's.  That should round down to 9 cpus.

BOINC regards a fraction of a core as able to be used so it will probably call 9.6 as 10 and do work fetch as if there were 10 running tasks, even with the limit of 8.

That won't matter very much as long as you keep the work cache to a modest setting.  In other words, a 1 day cache size would mean that BOINC should keep you topped up to (1*10/8) = 1.25 days worth for the 8 running CPU tasks, so not a huge amount extra.  If you see more CPU work than that ratio above your actual setting, the max_concurrent bug may still be active.

Cheers,
Gary.

Burned
Burned
Joined: 25 Jun 21
Posts: 24
Credit: 43,198,649
RAC: 3

Well, that absolutely did not

Well, that absolutely did not work.  A few hours after making the change the dreaded quota reached message appeared again and it ran out of GPU work units.  However, I now have 454 CPU work units in queue.  Averaging about 3 and a half hours per, running 7 at a time, that will only take 9 days.  Its a shame this project can't keep a recent vintage GPU fed with work.

archae86
archae86
Joined: 6 Dec 05
Posts: 3,021
Credit: 5,000,467,095
RAC: 3,001,458

Burned wrote:Well, that

Burned wrote:
Well, that absolutely did not work.  <snip>However, I now have 454 CPU work units in queue.

Sorry to hear that.

Quote:
Its a shame this project can't keep a recent vintage GPU fed with work.

Actually it can.  Quite a few of us succeed at this with just two tricks:

1. not running any CPU tasks
2. falsifying ncpu in order to get the quota limit up high enough.

I recognize that for you not running any Einstein CPU tasks may be completely unacceptable.  But I actively prefer not to.

1. Power cost is a major component of my cost of supporting Einstein, and the CPU applications are dramatically lower power efficiency per unit of useful Einstein contribution than are the GPU applications.
2. The scheduling scheme here works rather poorly with mixed work loads, so smooth operation for me has meant for years choosing just one GPU application to run at any given time.

These comments are not mostly aimed at you, Burned, but at any other participant who might come across this thread in the future.

Ian&Steve C.
Ian&Steve C.
Joined: 19 Jan 20
Posts: 916
Credit: 6,750,096,494
RAC: 21,828,404

It could be accomplished with

It could be accomplished with custom BOINC software. one configured to restrict how many CPU tasks that you're holding on to. This is personally what I have, though I'm not using this function for Einstein since I'm not running CPU tasks here.

you could also script a similar scheme, one that searches for extra CPU tasks and just aborts them, giving you more space for the GPU tasks. I admit that's a bit wasteful, but could work. something like this is easily accomplished with boinccmd.

 

Or, if you are willing to deal with split stats from your host, you can run TWO instances of BOINC. one for GPU processing (with inflated CPU count, for extra work allowance, and no CPU processing), and a second/standard instance for CPU processing. this will keep work fetch totally separate and will accomplish what you want, but history and stats will be split and the system will appear to the project as two hosts. 

_____________________________________________

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.