That's why I said that it may be an opportune time to lock as someone was bound to post a link to the blunt description and more. Thanks for not posting that.

When one is signed onto more than one project, what determines which ones they receive WUs from in what order?

It's random, based on what's in the shared memory at the time of work request (3,500 WU's I think). Since multi-project crunchers tap into the left-over pool that the exclusive crunchers did not snapped up, the ratios in that pool can be quite warped. You can have a selection of HFCC and HPF2 and almost only get HPF2. On one machine I'm having DDDT2/HCMD2/HFCC/RICE, I see rice 1 in 30 or so, no DDDT2 (we know why) little HFCC and lots of HCMD2. The scheduler over multiple days though tries to even out somewhat, but if there's little left for the pool, there's barely a chance to compensate.

What's overruling? On average WCG tries to have all projects get an equal amount of CPU time from the grid (see bubble chart link in my sig highlighting a present shortage of HFCC). The multi-project devices are acting as the adjusters to achieve that. Thus, this is why people juggle their device profiles all the time. WCG tries to provide work for general available tasks at all times to exclusive, single project crunchers.

long winded, hoping it did not confuse, then read again, Jean's post describing the general order quite clearly. Think knreed also made a post on this some months ago, so made a note to search it out and make it an FAQ linked item.

You're very welcome.

If you didn't already, you might set a profile to run nothing but Rice work units, with the other boxes all unchecked so the server doesn't send you anything but Rice... that should ensure you get 14 days of crunching time on that task so you'll get at least a bronze badge for NRW before it's finished.

Happy crunching. :)

Here an evolved version from the above. The % share per selected project was replaced by the estimated amount of work that would be send out on a longer period average. Per core for a project average speed device. If faster / slower do a multiplication or division to get to your host's estimated results per day per research.

There is no dynamic tuning, so the techs have to balance the feeders by hand based on measured actual run times, then set the daemon to send X per day, per work request, but that always on individual calls relying on what is actually in the feeder based on current demand.

The big IF in here is what is left for the multi-research crunching pool. Those on single project get 100% unless nothing is available in the feeders, either the client waiting on the next scheduled contact to get more or fetching work per the "If there is no work available for my computer for the projects I have selected above, please send me work from another project."

A practical example taking from the table below a HPF2/FAAH profile, per core the client could expect to see an average of 2.5 HPF2 results and 1.1 FAAH. Different run times, so different weighting.

See something conceptually wrong or mistakes in the calculation, let me know, but do bring the logic / support how you got there. In due course I'll be trying to put better Exclusive/Pool values, the techs might even share some real averages, so the micro-managers can optimize the badge aiming.

thx



Edit: Note to self: Add the single/exclusive project daily results per core to the table.