-
Notifications
You must be signed in to change notification settings - Fork 443
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
differentiate between number of CPUs to use in idle and busy mode #41
Comments
Commented by romw on 19 Jan 37319314 17:20 UTC |
Commented by davea on 9 Nov 37319324 11:33 UTC E.g.: if you use 1 CPU and it causes thrashing, your system will be sluggish. |
Commented by Pepo on 23 Sep 38902026 21:46 UTC Both ''Working'' and ''Idle'' states should contain a separately manageable set of ''"resources usage preferences"'' (CPU % throttling, %/number of CPU cores, memory usage, exclusive_app, etc.) just like it is now with preference sets for venues. |
Commented by Nicolas on 18 Jun 38902341 14:40 UTC |
Commented by Pepo on 20 Apr 40971453 15:06 UTC |
Commented by Ageless on 9 Jan 41894116 15:33 UTC |
And it's coming up again in the community responses to the request for input to the current working group. This is one of the oldest trac tickets still open - it's over ten years old, and probably more relevant to modern multi-core computers than it was then. |
Same request in #202 |
One challenge with this seems to be that there a number of different suggestions:
Is that a good summary? http://boinc.berkeley.edu/trac/wiki/PrefsRemodel covers a lot of this and more. |
Any significant features would require coordinated changes in a) the client, b) the Manager, and c) the web code. The idea of PrefsRemodel is to define a framework that's both simple and powerful. Namely, to separate the "triggers" (time of day, computer in use, maybe "app X is running", and so on) from the various parameters being controlled. |
When you will be working on it, please allow to define multiple profiles. I would like to have following ones:
It also would be nice if Gaming profile could activate automatically when BOINC detects full-screen app. There is separate issue for detecting that: #2301 |
Has there been any movement or thought on this? I have tried looking at the code, but I honestly don't know where to start |
I wrote a design for a super-flexible prefs system, but realistically that's not going to happen. |
Where could I find this in the code to look at it myself? I may be naive in thinking this, but couldn't it be a simple if/then or case/switch statement? INUSE ##% cores, EXCLUSIVEAPP ##% cores, ##% cores? |
@sinusoid2, that's not just a logic change, there should be also a user settings to control this and set preferred values for idle and busy mode. If you want to contribute to this, I suggest you to start looking at existing settings and their usage to understand to current logic of the scheduler and then try to understand how to modify it |
Here's a scheme with a couple of new prefs, organized better. Comments? When computer is in use When computer is not in use Jobs Disk Network |
David's proposal sounds lovely |
David, looks good. Small fix, your first line un in use should be something along the line of "in use" means input in X min (pull out the "no") |
I implemented the new prefs in the dpa_niu_prefs branch. Please review; I want to make sure people like this before |
Looks like one needs a login to see this? I am so excited for this change, this will easily double the amount of computational power I can give to BOINC |
It looks like SETI@home is used as a live test, so if you have SETI@home you can log in. If not, here is a screen capture: @davidpanderson, if we're looking for a broader pool of people to review and comment, I could post this on the BOINC message board (maybe a few other projects as well, too). Let me know what you think. |
This looks awesome!! |
@Vulpine05 Feel free to gather feedback - thanks. |
@davidpanderson will do. Its getting late and I want to be sure the message is well written, so I will probably get to it tomorrow. In the meantime, I'm going to play devil's advocate. On one hand, this looks pretty good. My only comments on this format would be:
On the other hand, I am sure some users are going to miss having CPU, network, and disk/memory settings bundled into those categories. So that everything doesn't have to get re-formatted and moved around, how about adding a second set of CPU usage and CPU time? Here is an example I just made in Paint: |
Looks good to me. I would like to see a further step personally. I know there are exclusive apps that stop it all together, but with so many cores even exclusive apps could probably just be limited to a user preference as well. |
That sort of thing would be handled by the ultra-general framework described here: |
I'll change "Tasks" to "General". "non-BOINC CPU usage" appears in both places because there are potentially 2 different limits, |
@davidpanderson, what changes, if any, will be in simple view? I think we should move the conversation for reformatting the preferences to another issue, also. |
Reported by KSMarksPsych on 12 Oct 37296831 05:46 UTC
Posted by:
Date: 3:05 PM 04-07-2007
BOINC detects if the machine is busy and can limit the number of CPUs to use. I'd like to see a feature, that I can define 2 numbers of CPUs to use, one if the machine is idle and one if the machine is busy. Right now I've got a dual processor machine and allow BOINC to use one of them so that my work is not slowed down. But when the machine is idle, BOINC could use both CPUs. Right now, this is not possible. With the advent of multi-processor/core machines spreading out to end users, this would allow more CPU power to be used by BOINC and the necessary preconditions are already implented.
Migrated-From: http://boinc.berkeley.edu/trac/ticket/41
The text was updated successfully, but these errors were encountered: