Maybe ignorant question twilyth: why do you need 10 days cache (or 8)?

AFAIK, the maximum number of HCC1 GPU tasks "In progress" per GPU in one device is 1200. Regardless your cache is 3 days, or 20 days.

The better solution IMO would be to start crunching with app_config instead of app_info what will in case of running out of GPU tasks allow you to utilize your CPU with some other WCG projects during outage (or you can add to app_info some non-GPU WCG project).

Cheers

Twylith,

If you allow at least 1 CPU project on top of your GPU activity, at least you can buffer more work to keep the CPU busy in case the interruption takes longer than whatever you manage to buffer for GPU. Strongly recommend to lower your MinB though to e.g. 2 days at most [CPU and GPU buffering are quasi separate]. Since in scheduling, at least with 7.0.xx, the GPU tasks get prevalence over CPU tasks, these wont be started until CPU cores are freed up by the GPU. In your case, with high power devices at least, not high buffering since there wont be more than 1200 per GPU and you'd be getting multi days of CPU tasks as well, which you probably wont want and would be stuck with them for longer when servers start providing GPU tasks again [and you get rid of enough "in progress", to be allowed more tasks] There will be an upload/reporting cram when the servers come back.

On the client side, 5000 per GPU card ""in progress" is calling for a party... that will bridge the 24 hour scheduled outage for 99.99% of the crunchers. There wont be resistance from the volunteers side :D

Daily quota of 6500 per GPU card... dont know how that meshes with 5000 in progress. Neither seems to be attainable in 24 hours ATM (Can't remember anyone having a brag post up with that type of value... more happy volunteer faces with these quotas).

I like the 50 per fetch limit, much better than 15 or 30, so at least the Maximum additional work buffer will lift the cache somewhat over the Minimum buffer level in the v7 clients [on the CPU tasks side]. For GPU crunchers it's doing little.

edit: But please, the work/generator/feeders need to be ready to withstand that extra pre-out suction. ;D

Kevin, re the below new server distribution settings:
Don't understand, still, this <max_wus_to_send>. Just tested by inflating my buffer setting on a quad and got 70 in 1 call, which is fine by me, but what does it... bug such as client to quick?. There's no 11 second out, so it's not like 2 requests got combined, or was there? At Seti at home the claimed that to happen "clients to quick", requests getting lost on the way and timeouts pumping more requests, which the server then happily executed.

17365 World Community Grid 1/19/2013 4:41:08 PM [sched_op] Starting scheduler request
17366 World Community Grid 1/19/2013 4:41:08 PM Sending scheduler request: To fetch work.
17367 World Community Grid 1/19/2013 4:41:08 PM Requesting new tasks for CPU
17368 World Community Grid 1/19/2013 4:41:08 PM [sched_op] CPU work request: 1365955.63 seconds; 0.00 devices
17369 World Community Grid 1/19/2013 4:41:14 PM Scheduler request completed: got 70 new tasks

So far, and this dates back months, seen the biggest award as 86-89 tasks in one fetch. As said, fine by me, long as it does not cause overbuffering [which it has not for my side].

To my knowledge there's no change between .28 and .42 on caching/buffering. Not aware that the added app_config feature of .42 in place of app_info does anything addtional, former's info does not get fed back to the server [will in a next client version]. So, yes I'd be interested if this is reproducible without changing anything to the prefs.