Once the work unit has validated successfully, all additional results are superfluous - for all projects except HPF2 (which uses a different quorum method).

However, extra copies aren't usually sent out unless one of the original copies is an error, or is not returned on time. There is very little wasted work.

Now just one cotton-pickin' minute there!!

Since a WU is distributed to a number of machines at substantially the same time, then the effect of a slow machine (in terms of return time on a WU) is this:

1. The points-allotment is delayed until the slowest returner has responded (this is only relevant to points-chasers)
2. The result returned by a slow machine is more than likely redundant.

It's this second point that is significant.

Take a simple case of a Quorum-2, Distribution-3 WU which is sent to 1 slow machine taking 8 hours and 2 fast machines taking 4 hours. After four hours, it's likely that a quorum would be achieved - the result are delayed to to arrival of the slow machine's response four hours later AND that response is redundant in any case. Sure - the two fast machines would be off doing the next WU, but the slow machine has been operating for 8 hours to produce a redundant result.

And so the slow machine lumbers on to the next WU - and again returns a redundant result. The nett effect is that despite running 24/7, the slow machine actually contributes NOTHING to the accumulated results, and delays the allotment of the precious points into the bargain.

The name of the game would be to get some nett work from the slow machines - not to ban them.

This could be achieved by better managing the distribution of WUs on a JIT-type basis. Send out the WUs in a pattern which would cause the responses to arrive at roughly the same time and set the deadline as say a day later. Only send out enough to fill the quorum. If the quorum hasn't been achieved by the deadline, THEN send out make-up jobs to historically-fast machines and wait for a quorum, repeating the make-up procedure if required.

The result should be that since the slow machines would then be making a contribution rather than perpetually returning redundant responses, then the efficiency of the entire grid would be improved. It would be like adding an extra perhaps 10 to 40% to the network by simply managing the resources better.

One more rule that became possible with the latest BOINC releases (5.8.16) and Server (509) updates: If there are known to be many redundant work units lurking around or a bad batch, WCG has the ability to send a cancel/abort instruction. It is only executed upon passive contact i.e. when the client contacts the server. knreed posted the rules somewhere but it goes like this piu o meno,

1. If the unit was not started, cancel the unit.
2. If the unit is known to be bad and started, abort the unit.
3. If the unit is known to be good, but started, let it run as WCG has no ability to discover if WU was in the first or the last minute. Credit is granted upon completion.

AFAIK this rule has only been deployed once or twice.

The passive contact may become active in the future i.e. a push towards the client, but that does not help if off-line. Many crunch that way and e.g. my IP changes presently about every few hours (and i feel saver somehow).

added: oh and the HPF2 each are unique and discussion is there to review and apply that logic of distribution and validation on future projects, but paramount is the validity which is deemed to still need 3 work units.

To think we came from an initial 4 distribution with quorum 3 just a year ago, efficiency was improved by about 30 percent (somehow I think to remember a published number of about 26%).

Sekerob, if WCG implemented a server push to the client, then you will lose a number of security minded people who believe that the server should only reply to a client request and never initiate the conversation.

No one more aware of that than WCG and i share your sentiments on that.

D. No thumbs work.... read it in the not to distant past and if slammed, shed no tear.