I believe that a proper analysis should not begin with leaping to an obvious conclusion.

As the system stands, we have three termination conditions for a pair of tasks:

1) Both run to completion.
2) One completes, but the other hits a barrier.
3) Both hit barriers.

Only the second two of these situations are of concern because the differential processing is wasted. In general, if one processor completes X and the other Y positions of a Z-position task then the processing of (Y-X) positions is wasted because two new tasks will be generated to complete X+1..Z [or four or more, depending on ((Z-X)/X)]

The closer X and Y are, the less is wasted, hence the improvement reported when tighter matching was implemented.

What I would propose rather than the let-it-rip scenario is this:

1. The returned result unit of Y positions be split into 2 separate returns, X and X+1..Y.
2. a single task be generated for the pair to X+1..Y (both scenarios 2 and 3) and two tasks for Y+1..Z (scenario 3 only)
3. Replace the processor-classification matrix with a simple (total-number-of-positions-recently-processed/total-number-of-minutes-required) calculation for the individual processor. Allot tasks to this processor which have a maximum of (400 minutes' runtime) positions.

If the returns were processed in this way, then the enemy, wasted processing, would be defeated. It would no longer matter what the differential between processors was as each would home in on its preferred task-size.

Certainly, the splitting operation would increase server-side load, but this would be balanced by the reduction in later-generation production (as processors home in on their 6hr run-time tasksize) reduction in tasks despatched (no re-processing) and no need for processor-classification logic.

The very slowest processors could then be given the very useful task of cleaning up the very small tasks that could result rather than attempting to swallow parent units intended for the ever-increasing power of the "average" machine.

And since it appears from the WU numbering that tasks of arbitrary size can be generated, it might even be possible to automate the sizing of tasks, dynamically creating bigger ones for the newer, faster machines as they become available.

And this would even let the old plodder P2/200s in the print-server retirement homes put the final touches once the speed-demons have done the bulk of the work.

Say Aye

Ok, 100% back to topic then.

If it's a matter of choice for the user: then yes, of course. Let the techs look at the feasability, the possible gain they can make. Taking in account weekends, smaller and larger holidays is something for the techs.

I'm most of the time "Pro-choice". Keep it simple for the mass, give options for the interested.

I like Mysteron's solution.

Maybe you've missed the word option in the title?