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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
_________________________________________________________________________
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.
Burned wrote:My computing
)
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.
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.
Burned wrote:Well, that
)
Sorry to hear that.
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.
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.
_________________________________________________________________________