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.