I have a machine with a 4 cores CPU (Q6600) and 4 GPUs (2x9800GX2). Due to the one wu per cpu, my machine is running dry several hours each time a wu is finished.
When wu is finish, scheduler starts upload result and asks for a new wu. For the server, wu isn't finish yet and answer the limitation. At this moment, on the client, next access to server is deleyed for several hours and the machine is running dry.


____________

(Sry for bad english)

I have written about similar problem in other thread (I have 3x280GTX). And 4 sure there will be more ppl (as me and u) with this specific problem.

My suggestion is to rise (rise up?) WU/daily quota (I need MINIMUM 12, but I would like to have more - if some errors...) and WU per GPU (up to 2 or 3 per GPU - to have bigger stock in case...).
____________

GDF, I think that 1 wu per gpu can't solve this trouble because of the scheduler work. 2 will be fine.

Thanks
____________

I have a similar problem. I have two GPUs in a PC with a two cores CPU. I have been waiting, client upgrade after client upgrade, the "2 or more WU/GPU" option, but it doesn't arrive.

I have a machine with a 4 cores CPU (Q6600) and 4 GPUs (2x9800GX2). Due to the one wu per cpu, my machine is running dry several hours each time a wu is finished.
When wu is finish, scheduler starts upload result and asks for a new wu. For the server, wu isn't finish yet and answer the limitation. At this moment, on the client, next access to server is deleyed for several hours and the machine is running dry.

Yes, 2 WUs per GPU is definitely needed.

Yes, 2 WUs per GPU is definitely needed.

I think n+1 WU's per system is a better compromise. It keeps fewer WU's in circulation while eliminating downtime between units.

Of course, this reduces to 2 WUs per GPU when you only have one GPU. But, four GPU's would get five WU's. Four in process and one ready to go.

Yes, 2 WUs per GPU is definitely needed.

I think n+1 WU's per system is a better compromise. It keeps fewer WU's in circulation while eliminating downtime between units.

Of course, this reduces to 2 WUs per GPU when you only have one GPU. But, four GPU's would get five WU's. Four in process and one ready to go.

n*2 would be better (I mean more logically) ;)

···The best would be # gpus + 1 extra··

I assume by n you are meaning # of GPU's

That would be better that what we have now, but IT IS NOT THE BEST. When I had a PC with two GTX280 (OC) I was doing 1 WU every 5.5 hours each GPU and sometimes I stuck wiht both GPUs iddle for 9 hours. If I had had 2 WU's in cache, it would have been ideal for me. And think about people with 3 or 4 GPUs...

Yep, problems with internet connection can always occur. Just before ur last post I thought about using <report_results_immediately>, but it will not help when no connection ;) :P.

Well, then I`m back with n*2. But I`m still thinking ;).

Mby better solution will be to use a lot of small WU`s (I mean something like WU with crounching time about 1hour at 9800GTX), with rules typical as for other projects? It will be automatically great solution for ppl with slow graphic cards, who are asking for longer deadline (as Krzychu P. - just to remind).
____________

Well, been giving this some thought.

Everyone has a this works best for me, unfortunately they are all different. Maybe once actual gpu prefs are separated from cpu prefs things will be better.

It is clear that gpu's need their own prefs, separate from cpu's, especially since the gpu is now being set to run all the time, or at least the two can share the same setting, but treated as two separate elements within the client's work fetch policy.

Now I'm thinking that even a limit of ngpu*2 would not be enough for some of the faster (5 hour) gpus's especially if they have a connect problem or only connect once a day, an always on connection cannot be assumed. They could easily use 5 per gpu per day and easily complete those within deadline. Even a three day connect interval could be used and still they could complete 15 per gpu within deadline. The limit needs to be based on a per gpu capability to complete work within the deadline, cache/connect interval, and not on a fixed max allowed. Since we have now between a 1 (slow gpu) to 20 (fast gpu) task need, within deadline, we cannot have a fixed limit for all. Even users with multiple gpus of different speed need a different number of tasks per day per gpu. Each gpu per host needs to be treated separately from the others.

BOINC needs to have a separate cache for gpu's just as it has for cpu's. All the prefs need to be used for both cpu and gpu cache's (such as connect interval), meaning not combined into one as some are now. If a user has specified a 24 hour cache, BOINC needs to have 24 hours of cpu work per cpu PLUS 24 hours of gpu work per gpu, adjusted to resource shares of course if you have multiple projects where cpu projects effect only the cpu cache and gpu projects effect only the gpu cache, and adjusted by the DCF to be sure that many tasks can be completed within deadline. The cpu cache needs to be reduced of course by the time the cpu part of the gpu tasks will use, which currently is different for different os's, linux only being 2% usage and windows being 40% useage. That coule be on a per hosts basis and averaged jsut as current DCF is for cpu projects. Again adjustments need to be made for slower gpu's that will not finish two tasks within the deadline, they would only get one at a time per gpu, otherwise the second waiting task would not finish within the deadline once it starts. Any gpus that can finish more within the deadline can have more, up to cache size if that many can be finished within deadline, per gpu.

I'm sure BOINC can be made to do this, it will just take some time and effort to get the server scheduler and client work fetch and scheduler all fine tuned.

I will pass this whole thread on to the boinc developer, if these changes have not already been started, at least this info will help shape what may come.