It seems inefficient to send out 'extra' copies of a WU if they will just be rejected on return. If the quorum is set to three to validate a WU, why not just send out three, and if a straggling WU doesn't come in for a while, then issue a fourth?

Even if the fourth arrives before the straggling third, it seems to me there is still value in assessing the accuracy of the third, even reopening 'closed' database rows. While you may choose to not 'score' it the same since it didn't arrive promptly, it seems they can still have worth by further reaffirming the quorum value and the computational accuracy of the client.

---

It seems inefficient to send out 'extra' copies of a WU if they will just be rejected on return. If the quorum is set to three to validate a WU, why not just send out three, and if a straggling WU doesn't come in for a while, then issue a fourth?

This was indeed done when the project first started and has been hotly debated since.

Looking at the return statistics, something less than 25% of WUs do not get returned before the deadline. Sending out an extra WU copy immediately in anticipation that perhaps one will be 'lost' speeds up the whole process.

If very few WUs were lost by users, then your scheme might come back into favour.

Regards,
Martin

---

See new freedom: Mageia Linux
Take a look for yourself: Linux Format
The Future is what We all make IT (GPLv3)

According to my study of about 6 months ago. with an issuance of 3 there was a 53% success rate and with 4 issued results that rate went up to 74%. Now if they were to issue 5 then the success rate went up to about 85%.

The majority of errors that delayed the quorum were the "over-no reply-new" or people returning work late. The download errors where by far the largest, but since they reissue work within a day or so when a Download error occurs, this didn't really slow down credit or the development of a canonical result.

I haven't done a study since they stopped pre 4.19 clients from getting work, and I'm sure it'll help reducing the number of d/l errors.

---

According to my study of about 6 months ago. with an issuance of 3 there was a 53% success rate and with 4 issued results that rate went up to 74%. Now if they were to issue 5 then the success rate went up to about 85%.

OK, checking my rough calculation against those numbers gives:

(Assuming failure is due to only two results returned)

3 issued: 16% loss
4 issued: 13% loss
5 issued: 9% loss

And:
3/3 = 100%, 16/16 = 100%
3/4 = 75%, 13/16 = 81%
3/5 = 60%, 9/16 = 56%

Which I think suggests the loss rate is approximately randomly spread if the sample size was small. Or if the sample size was very large then those failures are a little skewed by some other effect.

Further thought: 'failure' for 4 and 5 issued will underreport for where only 1 or 2 results respectively are lost. Still doesn't precisely fit though.

(Or I'm babbling randomly :( )

Cheers,
Martin

---

See new freedom: Mageia Linux
Take a look for yourself: Linux Format
The Future is what We all make IT (GPLv3)