Ability to tune the app to meet the needs of faster GPUs inoder to fully utilize them. Some gpus I would want to push to the limit while still providing valid results, others I would want to be able to tune for good results without affecting the user experience while doing other activities on the machine (reduce visual lag).

While most of those replies do address how to make a wu run faster, they don't address the wish list request.

GPU clock and fan control are well known for controlling the speed of the wu on the gpu, but the advice doesn't address the wish to control % of GPU usage.

Running things on Windows 7/8 at higher % utilization on gtx 680 and up is not an impossible task, it is being done elsewhere. Getting more loading on a gtx 680 gpu is possible by running 2 wus with free cpus, but that still only gets it to 97%. Recommending people to move their GPUs to a different or older version of OSes is an interesting approach What is the percentage of the GPUGrid users using Windows 7/8?

Clock speed isn't what I was considering when I was wishing for utilization. My hope was the application might be able to allow users to tune the number of concurrent items the tasks send to the GPU or adjust threads to push more work at the GPUs that still have more to give. I understand the need to make sure default setting work on all/most supported GPUs, just wishing for a method to change the defaults. Maybe an optimized version of the application for the new architectures is needed.

On collatz, I like Slickers approach for those wus, I can push one gpu really hard, but tune the gpu engine I use on a daily basis back from the edge to prevent laggy performance on the screen. Just wishing for some kind of version of those features here. Of course I understand it may be different types of tuning for different types of application and Collatz and GPUGrid are different programming problems.

Sorry for the wordy response.

While most of those replies do address how to make a wu run faster, they don't address the wish list request.

And maybe that is the answer "The project defines it’s research into the generic areas of Cancer, HIV/AIDS, Neural Disorders and Methods, however there can be several lines of research on-going within any of those categories at any one time. The WU types change frequently, so it would be infeasible to allow the selection of WU types; thousands of people would have to log in regularly and reconfigure their settings correctly. Support would become very difficult in what is already a difficult project to support. The projects research continuously changes."

Give people the option of what kinds, generically speaking of course, to run, making them better able to tweak their own pc's. Instead of only giving them these choices:
Run only the selected applications ACEMD short runs (2-3 hours on fastest card): yes
ACEMD beta: no
ACEMD long runs (8-12 hours on fastest GPU): no
test app: no

Change that so it lists your generic types instead, then ALSO change this default:
If no work for selected applications is available, accept work from other applications? no

to YES so that if people run out of Cancer units they will automatically get the other kinds.

If people could stop getting wildly different types of units maybe they could tweak their pc's to be better for them, and ultimately you. Yes it may cause your stats to change, you could be out of Cancer units and have thousands of Hiv/Aids units left uncrunched, but if you play around with the credits slightly that too could change. ie as your internal deadlines/goals approach offer more credits for the units you want crunched more quickly. What I am trying to say is instead of using a take it or leave it approach, try a more let the user decide and work with them, via the carrot and the stick, to guide them down your yellow brick road to your goals.

Ultimately this could even benefit future workunits on your end as you find more people using this or that gpu on Cancer units you could tweak those units to best run on those gpu's. We all have reason why we crunch, loved ones lost to this or that disease, the idea of aliens coming, rocks hitting the Earth, etc, etc. Let us help you and you might be surprised where it can take the two of us.

You must already know about DistRTgen and the outrageous amounts of credits they give per workunit, and have decided not to even try to compete with them. People are here because they want to be, not just for the stats. Let's work together to solve your ultimate goals and just maybe we can both be a bit happier on the journey. MANY years ago Seti did the 'slam bam thank you mam' approach, and although they do still have the largest numbers of initial crunchers, they ALSO have the largest numbers for people leaving too. They too have now decided to be, at least slightly, more user friendly. They now shut down 'for maintenance' regularly, they have reportedly stopped reissuing workunits just to keep the work flowing, etc, etc.

@skgiven,

Well said! That sums it up completely, coherently and concisely. An excellent piece.

@Mikey,

Good points regarding allowing volunteers to select the types of tasks. It's a good idea but would be difficult/impossible to implement in a way that doesn't require even more work from the admins/dev on a continuing basis. If you don't program then it's not easy to understand why it is that way but it is. Not saying I'm a programmer genius but I've been doing it long enough and have attempted such a variety of applications that I can say with confidence it wouldn't be feasible to do what you want the way you suggested.

Fortunately, there may be another way to do allow crunchers to choose which task types they run. I've floated the idea before and asked the admins for their thoughts on the matter and haven't received any reaction. So the next step is to force a reaction by implementing my idea. If it meets with approval then OK; if it's condemned by admins or users I'll disable it.

The plan is to provide a script that runs on our hosts, not the server. The script will allow users to "block" task types that do not run well on their host. It could also attempt an analysis of why tasks are failing and noffer suggestions on how to remedy the situation without blocking tasks. The problem is that the script can't actually block any task from being downloaded onto the host. It has to wait for whatever task comes down the pipe and abort it if it's on the user's blacklist. The potential problem is that if ba system aborts too many tasks in one day the server might refuse to send it more tasks for 24 hours. But what is the sense in accepting tasks that will likely error anyway?

I'll code it and test it. If it doesn't work out then there may be work arounds. For example if a user has 2 GPUs (say a 670 and a 780) and finds type A tasks runs OK on the 670 but not on the 780 then maybe the script could make sure type A tasks run only on the 670 and not on the 780. It may even be possible to direct task types to different hosts on the same LAN in case your 670 is in a different box than your 780, i.e. the old sneakernet concept but automated. And if it works across a LAN then why not over the WAN?

That's doable and it wouldn't require a lot of code maintenance on my part after the script is debugged and working properly.

____________
BOINC <<--- credit whores, pedants, alien hunters

Please keep in mind this is a wish list item, not I think you are doing a bad job and should change to suit my needs item. The initial reply was in a different direction than I anticipate with my intended wish, so I clarified at greater length (too much I think).

Ultimately this could even benefit future workunits on your end as you find more people using this or that gpu on Cancer units you could tweak those units to best run on those gpu's. We all have reason why we crunch, loved ones lost to this or that disease, the idea of aliens coming, rocks hitting the Earth, etc, etc. Let us help you and you might be surprised where it can take the two of us.

@Variable. I understand your point but selecting projects would be very counterproductive to do here unfortunately. We would cause ourselves more harm than gain.
We use priorities for our tasks which are chosen internally for each project based on the urgency of finishing it as well as the total amount of simulation time needed. If users could override this setting we would be essentially fighting against you.
Also users all moving priorities to a specific disease would eventually force us to change research direction even if we don't have anything to research in that direction which could be a horrible waste of resources.
I don't know how they do it at F@H but I would have my doubts about how seriously they take these priorities.

@Stefan

This thread has split into 2 different wishes:

1) a wish to have options in website preferences that would allow volunteers to decide how much to load their GPU, by "load" I mean how hard it works not which task type it works on

2) a wish to have options in website preferences that would allow volunteers to select which task type to work on

This thread started off with a wish for 1 and has now evolved into a discussion of wish 2, not that I am complaining about the change of direction, just attempting to clarify.

As per your advice in your previous post in this thread I will not, at this time, develop a script to allow users to filter out unwanted task types. I may at some time in the future but only if I can think of a way to prevent the problems it would cause. Thanks for your input on the idea. I never truly liked the idea due to the reasons you mentioned as well as the fact that some task types earn slightly more credit per hour than others and I can see how some volunteers would filter out low paying tasks in favor of the higher paying tasks. In the highly unlikely event I decide to pursue it again, I will inform project devs. The best way to solve the problem is proper host configuration which could mean adjusting parameters such as clocks and voltage on the fly via a clientside script. I might look into that possibility after I deliver on other commitments I've made regarding Crunchuntu.

____________
BOINC <<--- credit whores, pedants, alien hunters