Opened 17 years ago
Last modified 13 years ago
#310 new Enhancement
Ceiling on the # of Wu's open per project
| Reported by: | Owned by: | jm7 | |
|---|---|---|---|
| Priority: | Minor | Milestone: | Undetermined |
| Component: | Client - Scheduler Policy | Version: | |
| Keywords: | Cc: |
Description
I have a requirement that I can't keep a lot of unprocessed work down on my multicore machine. I need to be able to drain it fast. To that end I have shut off extra days work parameters.
My BOINC client box still gets over committed because BOINC "fetch_work" tries to pull down enough work to keep all CPU's I declare busy even with the backlog switches set to zero (workdays 0, connect time .001). If several projects are suspended, those that aren't suspended keep pulling down wu's until all the other parameters (debt) are satisfied unless I also manually shut off work requests. The resulting load is lopsided. The scheduler is sophisticated but at the same time lacks the basics. All I want is to impose a limit (a ceiling) on the number of wu's any one project in my cache of projects can have open on the client. I want most projects to have no more tthan 1 wu running, two at the most, and no tasks waiting.
I'd rather just say "project you have one work slot (task runner) or two work slots (two task runners)" and say "Scheduler - keep the project's work slots I set for this project up 100% busy and -running- as long as there is work for that project". Very simple.
I want this proposed wu limit to apply PER INDIVIDUAL PROJECT, not per the whole BOINC work cache. The parameter setting description would read: "This parameter causes any BOINC project to stop issuing work requests once the number of work units downloaded for any one project equals the number set in the parameter. Completed work units waiting to report do not count in the computation of this maximum. Setting the parameter to zero disables it (default)."
It would be even better if this parameter was -separately settable- per -each- project. but a global setting that limits each project is good enough. I read lots of posts on the boards complaining about troubles balancing the workload evenly across projects on multicore systems like mine. I believe, properly implemented, this feature would solve most of those issues. Superlink project is an extreme example of an application that could really benefit. CPDN in a mix of smaller wu's from other projects is another.
Change History (8)
comment:1 Changed 17 years ago by
| Component: | Undetermined → Client - Scheduler Policy |
|---|---|
| Owner: | set to davea |
| Priority: | Undetermined → Minor |
comment:2 Changed 17 years ago by
| Owner: | changed from davea to jm7 |
|---|
comment:3 Changed 17 years ago by
comment:4 Changed 17 years ago by
Re-reading this, it is apparent that BOINC is working as designed. If there are unused CPUs that are allowed to have work, and there are projects that can supply work, then BOINC is supposed to keep those CPUs busy. If the user wants to reduce the number of CPUS used, (s)he should set the number of CPUs down.
comment:6 Changed 17 years ago by
Replying to Nicolas:
Should I close this as invalid?
Yes. I requested more information about the actual problem, and there has been no further comment for almost 2 months.
comment:8 follow-up: 9 Changed 13 years ago by
6.12 and earlier would attempt to keep tasks from every project on the client all the time unless the LTD was too negative. 6.13 stops attempting to fill the buffer when it is full even if that means that some projects that have a work fetch priority that would allow them to fetch work don't have work on the system.
4 years between comments?
With "Connect every X" and "Extra Work" both set to nearly 0, there should be at most one task per project with the exception of projects that have a resource fraction that is higher than 1/ncpus. If this is not already the case, then there is a problem with the calculation of work fetch.
The description is not what is happening, it includes a supposition about what is happening. The client does not take debt into consideration when calculating the amount of work to fetch (it does take debt into account when determining whether to fetch work at all). Details about the behavior are needed.
Please check the values of work_buf_min_days and work_buf_extra_days in the global_prefs_override.xml, and the global_prefs.xml file. If multiple venues are used, please check that the correct venue is being used. Note that these files are NOT per project, and the venues are NOT per project.