.....and not forgetting the massive bandwidth required on the upload which has nothing to do with the PC in use either

WCG does the erring on the lowest common denominator side i.e., yes if new members really came with latest up to snuff stuff, very maybe, but the reach out is to everyone who ever hears of WCG with a quite low base spec of device, so defaults can't possibly be set to an all-out-max... a recipe of ''how to loose...''.

That said, once we see WCG endorsing their 7.0.xx client and it's app_config.xml feature [I've been beating the drum on], we may be seeing a more active drive... Doubling would be great, but think already going from ~18y to ~23-24y/day is substantially creditable to users taking on the <max_concurrent> setting [knreed said he can't measure this presently]. The WCG client will also tell the server what the app_config content is, so it can tune into providing enough work that the maximum per spec are running... e.g. if max_concurent CEP2 is set to 2 and client specifies 1 day buffer on a quad, make it have 6 ''in progress'', so any buffered CEP2 is oldest and therefor will always be first in wait to be started. Been doing this myself since first introduction through the 7.0.40 [test] client.

edit: Of course, if you specify CEP2 only for WCG, that's all you get... 6 with 2 running in the example. Make sure you have other projects selected, or cores run idle. The other projects will top up the buffer and run as and when it's their regular FIFO turn [in a non-panic order state of client].