application Rosetta Beta
created 23 Oct 2007 23:31:06 UTC
name 5croA_SEARCH_PAIRINGS_CONTROL_ROUND2_SAVE_ALL_OUT-5croA-_BARCODE__2199_7646
minimum quorum 1
initial replication 1
max # of error/total/success results 1, 2, 1
Result ID
click for details Computer Sent Time reported
or deadline
explain Server state
explain Outcome
explain Client state
explain CPU time (sec) claimed credit granted credit
114879214 97881 23 Oct 2007 23:31:58 UTC 4 Nov 2007 20:30:12 UTC Over Success Done 9,182.51 22.98 23.94
117433765 510574 2 Nov 2007 23:32:17 UTC 12 Nov 2007 23:32:17 UTC In Progress Unknown New --- --- ---

Seems there is no point in running this WU as it was completed on 4 Nov

---

I think that's one of those annoying times when someone doesn't finish their work on time, so a unit is sent out again. Only then the late guy returns the work and the guy who got it fair-and-square on the rebound crunches for nothing.

People who don't return their units on time should get 0 credit instead of the people that get the unit on the rebound.

---

Agreed! Been caught before so I check all WU with ...1 as the last digit.

---

I agree that duplicate processing would be pointless in this situation.

But to treat the credit system fairly:
In my experience (and with a consistent workload covering 6 days I have some...) you would have received your due credits crunching as #2 in the queue if #1 beats you although overstepping his time limit.

The problems appear when you receive a wu as #3 in the queue. With #1 being too slow and #2 having a computing error the negative results in total seem to block Rosetta from issuing credits for successful results from cruncher #3.

This programming issue should be fixed (in Boinc?) as soon as possible.