Hi,


I couldn't find a "new features request" or "feedback" link, but I have a configuration related suggestion.

It would be useful to be able to set "Use at most <###.##> % GPU time" separately from "Use at most <###.##> % CPU time".

My GPU is newer and runs cooler than my CPU. Some projects rely almost entirely on the GPU. It is spring here in Argentina and hot days are coming soon.


Best regards,
Nicola Bernardelli

Going to see if it can be done with TThrottle http://efmer.eu/boinc/
which I just found mentioned here http://en.wikipedia.org/wiki/World_Community_Grid

I moved your request to this thread, as it had nothing to do with the thread you posted in. That thread was about an easy way to change the options in the cc_config.xml file, not about adding things to BOINC its code.

Your request to add GPU throttling is one that comes by every now and then. It's not easily done, it is on the long developers to do list. In the mean time, and as long as you runs Windows, you may want to look at TThrottle, which allows for throttling of the GPU based on temperature.

I need an option where I can tell the client that GPU has high priority with full CPU usage.

Why? Always CPU cores are getting the full usage and the GPU project (Milkyway) get the rest.

How should it work (example):

GPU usage is taking 10% of CPU power (now running only with 5%)
Spread the usage (for 4 cores):
GPU=10%
CPU core1: 97,5%
CPU core2: 97,5%
CPU core3: 97,5%
CPU core4: 97,5%

At this time to get the full advantage of GPU is to set CPU cores to 3 but this wasting 90% of 1 CPU core.

Sure you cannot define a app_config.xml for your GPU project to allocate a CPU fraction [non-intense]? That could make the remaining CPU part available to a CPU task. Visit the Milkyway forums ... maybe they've posted samples of an app_config.

---

Coelum Non Animum Mutant, Qui Trans Mare Currunt

Hi there,

it would be great if the Windows client could detect the AVX feature on newer processors to avoid working with an app_ino.xml on some projects.

Many thanks

Is it possible to have an option like:
On GPUs, use at most x% of N Compute Units. So that the first (1-x)*N CU are not used by BOINC. Maybe this could help decrease the screen lag for projects which need to modify their application to avoid this issue.

based on http://www.anandtech.com/show/7643/amds-kaveri-prelaunch-information

Are there any near plans to consider assigning tasks to gpu based on Compute Units.
The reason is the following:
If 1 out of every 8 laptops is crunching a gpu project (and burning the gpu :) )
the same number of WUs can be returned if each of those 8 laptops is crunching on 1 Compute Units (E.g. out of a maximum 8 Compute Units)

Hopefully if the other 7 GPU CUs can have a lower frequency or may be even turned off, it will solve also the thermal issues.

Are there any near plans to consider assigning tasks to gpu based on Compute Units.

BOINC doesn't assign anything according to internal parts of any piece of hardware, it will only do:
CPU? OK, if the project has an application for your CPU, I'll schedule work for it.
GPU? OK, if the project has an application for your GPU, I'll schedule work for it.

If anything were to assign tasks based on amount of compute units, it would be the science application first, as that will have to decide if it wants to use all stream processors, or only a few. Thus also if it wants to use all compute units, or only a few. And only if the project has an OpenCL application, and then only if that application can actually run on the CPU or GPU, or maybe in the future on both at the same time.

So you'll have to ask at the project of interest first.

Now, throttling based on amount of compute units might be possible to be done by BOINC, I'll forward that request to the developers. But appointing tasks to CUs is definitely done by the project's science application.

I would like to suggest an improvement in the scheduler.

I think it would be useful it there are downloaded as many tasks as are a multiple of active cores (taking potentially settings in the app_config.xml or other project specific pref files into account).

For example: I have an Phenom II X4 (= 4 cores), which are all active on BOINC. So it would be useful if the scheduler grabs 4 x X WUs. The number X would needed to be computed (or roughly estimated) by taking the prefs options Maintain enough tasks to keep busy for at least Y days and Up to an additional Z days amount into account.

Currently the scheduler does not work this way, it does get quite some WUs which mostly leads to 1 or 2 being left over, meaning that the rest of the cores goes idle.

I should mention that I do not let my BOINC run all day and night, but get some WUs which it processes until I am back home...

Run the projects (and maybe boinc.exe) as a different user on windows.

This is not the same as a Service Install. Boinc is started on a user login, not at computer startup. (And it is probably also stopped on logout.)

I tested: I started boincmgr as a different user. (boinc is not running. Then SHIFT+right click on boincmgr, select "Run as an other user" and enter the credentials.) Now boinc.exe and the projects are started as this other user too. The GPU tasks do run without any problem. When I quit boincmgr without stopping the client and normally restart boincmgr, it connects successfully and everything still works fine.

Suggestion: boincmgr starts boinc.exe as an other user (if configured to do so).
Or maybe boinc.exe is started by the task scheduler on a login event. The different user can be configured there. But I did not test if the GPU-Tasks work like this. (I can not set the right "Logon as a batch job" for the user.)

Running by the task scheduler does not work. (The GPU is not found.)
So remains the first suggestion, boincmgr starts boinc.exe as a different user.

I have two suggestions for the backlog time:

1. maintainance time should be reduced from 60min to 15min
2. for computation errors, dont raise the time for every WU error, if you have good results too all cores went idle, waiting to get new work. To avoid that problem is the daily quota for bad results.

My Wish - Command-Line Interface Only Android BoincClient

Build the command line only client maybe with C4droid-IDE or
CppDroid-IDE ?

To be honest, I find that the v7.0 scheduler is much more tightly integrated between CPU and GPU than the old one was.
But with v7, all crunching (whichever compute unit) goes into a 'common pot' of REC - and if you crunch GPU for a project, BOINC vary rarely schedules CPU work for that same project. They're interlinked.

Sometimes my pcs continue to request ONLY gpu work from projects without gpu support (like rosetta). I suspend use of gpu, i retry to get work, but continues the gpu request. Solution? I make a cpu benchmark from manager and i restart to download wus for cpu!!!

How about an option to ignore the idle timer when the computer is locked? I keep BOINC on a long idle timeout since my CPU fan is really noisy, and I regularly work in the same room as my machine. However, this results in quite a bit of wasted time every time I leave to sleep or whatever, or bump my desk hard enough to move the mouse a bit.

This is probably dependent on whether each OS provides a way to see if the console is sitting at a lock screen or not.

I know this has been requested (and denied) in the past, but I'm hoping the dev team can reconsider automatic updates.

I'm considering a johnny Appleseed-esque crusade, wherein I acquire cheap desktops, plop in the best possible specs for the best price, install the boinc client, and then give the computers away for free (to those with internet cnxs). Boom - 2-4 new cores crunching away.

The problem is that without automatic updates, these "seeds" will become useless as BOINC gets updated, unless the receiver knows how to update ... and this requires a level of involvement that wouldn't mesh with this type of effort.

So perhaps an "enable automatic updates" option? Or a program that can be co-installed, such that the primary boinc client software is free and clear of this exploitable code, but the option still exists?

Actually this sounds like something a 3rd party developer could whip together. If only I could code.........

Hi!

What I would really like to see because it would be a great ease:
If you double-click on a task, the "properties" windows for that task opens.

Until now it's: Click on task -> click on properties -> properties window
opens. If you want to check on more than a few tasks, this procedure is quite annoying.

Thanks.

Hi!

What I would really like to see because it would be a great ease:
If you double-click on a task, the "properties" windows for that task opens.

Until now it's: Click on task -> click on properties -> properties window
opens. If you want to check on more than a few tasks, this procedure is quite annoying.

Thanks.

+1

I've absent-mindedly double-clicked on a task before now, expecting that would be the natural thing to happen - and been mildly irritated when it didn't.

Hi!

What I would really like to see because it would be a great ease:
If you double-click on a task, the "properties" windows for that task opens.

Until now it's: Click on task -> click on properties -> properties window
opens. If you want to check on more than a few tasks, this procedure is quite annoying.

Thanks.

+1

I've absent-mindedly double-clicked on a task before now, expecting that would be the natural thing to happen - and been mildly irritated when it didn't.

*bump*

It would be REALLY nice it you could add an option like


For MutliThreaded WUs, use XX% of processors


I've had problems where a project with VERY short deadlines download enough WUs that they immediately go into EDF mode, which excludes work on any other project until the backlog is cleared

With this option, I could for example limit MT WUs to 6 of my 8 processors, and let the Scheduler portion out the remaining 2

With this option, I could for example limit MT WUs to 6 of my 8 processors, and let the Scheduler portion out the remaining 2

The multithreaded application decides how many threads to use to do a task, not BOINC. So if this were to be an option, it would be one set through the project's preferences, and then you'll have to ask the project for such an option.