You guys are running our application under bOINC more than us, therefore have a better vision of things at which the BOINC client is not doing well related to ACEMD. Please report it on this thread, we discuss the priority and try to push the changes into BOINC.
We are interested in things which affect us, for general BOINC problems you have the boinc mailing list.

For instance, let's start with a couple of topics.
1) The new BOINC screensaver seem to blow it up. Could you report it more in details?

Thanks for your help,
gdf

2) Strict FIFO does not allow long queues to be used or for Resource Share to be respected if more than two GPU projects are run at the same time.

This is the king of things that should be reported to BOINC directly.
Here is for project specific issues.

gdf

How about allowing specific GPUs to be enabled/disabled ie disable GPU1 on a gtx295 while leaving GPU0 enabled

How about being able to disable screensavers on some GPUs (such as those used by GPUGRID) but not others (such as those actually connected to a monitor, if there is no overlap) in multi-GPU situations?

Also, if we can first persuade Nvidia to add a function to their drivers to detect whether the monitor is connected and turned on, an option to automatically disable the screensaver on a GPU if the monitor connected to it is turned off or none is connected. (Leave it an option in case some monitors are unable to tell the driver that they are turned on.)

How about a function to detect whether the BOINC screensaver is about to run or currently running, so that GPUGRID has the option to pause the workunit, wait until the screensaver has either blanked the screen or stopped running, then restart from a checkpoint?

How about an option, applicable mainly to laptops, to set a different amount of time BOINC can continue running without user actions when on batteries, and when on wall power instead? This should include the option to allow running indefinitely when on wall power.

How about an option for GPU workunits for the CPU part to include a parameter for telling BOINC that it wants to be responsible for deciding how long to wait before deciding whether to abort if the GPU is unavailable at present, instead of having BOINC immediately abort the workunit automatically?

This is the king of things that should be reported to BOINC directly.
Here is for project specific issues.

It has been, and it is a project specific issue in that you, like MW, could lose significant capability because Resource Share is over-ridden by strict FIFO ... but, up to you if you are not interested in fighting for your proper Resource Share ...

An awful lot of BOINC's behaviour is still inherited from the earliest days: implicit assumptions that there is only one computing resource (the CPU, even if there are multiple copies of it), and that each project only has one kind of application to run on that CPU.

I'd like to see a lot more of BOINC's control functions (both user controls, and internal automatic controls) reviewed and relocated to take account of the new multi-resource, multi-application environment.

We had a big step forward recently, when 'use CPU', 'use NVIDIA', 'use ATI' were made into preferences which actually controlled work request behaviour. Here's what it looks like, for those who haven't seen it yet:

11/10/2009 11:41:39 GPUGRID [wfd] CPU: fetch share 0.00 debt -404704.37 backoff dt 0.00 int 480.00 (overworked) (blocked by prefs)
11/10/2009 11:41:39 AQUA@home [wfd] NVIDIA GPU: fetch share 0.00 debt 0.00 backoff dt 0.00 int 0.00 (blocked by prefs)

So, I won't bother pestering GPUGrid for CPU work, or AQUA for CUDA work - perfect.

The next one I'd like to see moved to being a project control, rather than a BOINC-wide control, is 'Use GPU while computer is in use?'. I find GPUGrid to be pretty 'friendly' while CUDA apps are running - there isn't much display lag or jerkiness. [For ordinary text-based work - I'm not speaking as a gamer here]. But some CUDA apps (AQUA, SETI VLAR) made the computer almost unusable, so the control to disable the GPU was introduced, and defaulted to 'on'. You will be losing a lot of crunching power to this. Making the option project-specific, and defaulting it appropriately, would make better use of the resource.

Then there's the thorny problem of work estimation and DCF. As I've said here before, badly-estimated work is a particular problem for new joiners (with a default DCF of 1), but is hidden from the old hands by DCF. Until you add a second application - ATI/OpenCL, for instance. Anyone running both apps will quickly notice that a single DCF can't track both of them. BOINC needs to hold and update separate DCFs for each app_version, otherwise BOINC will be in danger of fetching too much work and returning it late (particularly relevant to the quick turnround you strive for here).

This is the king of things that should be reported to BOINC directly.
Here is for project specific issues.

It has been, and it is a project specific issue in that you, like MW, could lose significant capability because Resource Share is over-ridden by strict FIFO ... but, up to you if you are not interested in fighting for your proper Resource Share ...

A short view on RAC share of the big teams suggests this question has been answered. Not sure why I should engage more in a project which forces me to disable the cache for my best running app and gives out the lion share of credits only to those having a GT200 chip. Additionally, from one day to the next, we may be told that we are surplus to the needs, just as PS3 owners have been lately.

No offence meant, but in my eyes this is looking really dubious.

---

Hi!

I am switching right now from nVidia to ATI, so it is naturall that if I want support GPUGRID I, and other users with ATI needs app.... for ATI....

---

POLISH NATIONAL TEAM - Join! Crunch! Win!

I would like to see some manual controls, such as processor affinity and the ability to limit the number of CPU cores a given project can use at once. Some projects use huge amounts of ram and only work effectively if limited to one or two cores of a quad. Also the ability to assign a backup project(s) that will DL and run one WU at a time only as needed and only if the main project runs out of work.