As many crunchers are acutely aware, the server side has little control over how many tasks at how many hours per day/week/month other than playing the quantitative number of work units in the feeder, a manual balancing act by the WCG Techs. Most pronouncedly is the current CEP2 overflow into the mix pool. Those that have multiple WCG sciences selected and taken off the bandwidth check AND the "1 per host in progress", see near total domination of CEP2 work in crunched/contributed hours.

Now the suggestion: The client keeps a per-attached-grid control over resource-share/project weight i.e. how much work is done for grid A/B/C, so thought occurred (and many new to WCG having sought in vain in their project pick list) of WCG creating urls or url subs (cost minimal) specifically so that members who want to attach to science X/Y/Z, still associated to the standard profiles, so that a client will fetch, assuming a default of 100 resource share, over time an equal share of work. In example:

www.worldcommunitygrid.org/HCMD2 - 100 > 25%
www.worldcommunitygrid.org/DDDT2 - 100 > 25%
www.worldcommunitygrid.org/HPF2 - 100 > 25%
www.worldcommunitygrid.org/HFCC - 100 > 25%

All works out to 25% per science to WCG internal, and does not compromise the share of projects outside WCG i.e. 4 attached sciences translates to 400 total for a client and by playing that number, can be used to control the overall WCG contribution.

The client would do the accounting through the STD/LTD method and when there is no work of X or Y or Z, back fill with any of the other available and as soon as e.g. the much coveted DDDT2 is available, prod that feeder a little more often. Any science that incurs a supply chain kink for a period of time would build up STD/LTD (Short and Long Term Debt), and thus on resume would receive a more attention by the client.

It's not like the "I want to control the exact percent per science", but at least facilitates an equal sharing and then from within the client have the possibility to suspend work fetch for each individual when wanting to reshuffle i.e. suitable to the small cruncher. Those that have farms can shuffle by associating clients to different device profiles, which as we know has the possibility to create more than the official 4, at WCG only!

On WCG's side, don't know how the server would account for multiple attaches to the same client. Would this create issues? The path is that a client requests specific work.

Please for anyone having input to this "solution", stick to developing this approach and not inject another dozen variations of how you want it... most all have been discussed in other threats, so please revisit those. Question is: Would this work / Could this work and is it implementable without tearing down the house and require a rebuild from scratch, which is the last thing I want to push.

Sort of a discussion outline and thx for reading and sharing thoughts, constructively.

--//--