Based on the I, my O asessment ended up with: Quorum 2 all the way to the end. How else could you build a truly reliable cancer markers database? Already heuristics were applied to filter the I side as else the task would have become too great [but, as with HCC, would there be a GPU build, that what is currently defined as workset could get an expansion... or not, [read on my ramble]:

And to ask the question more forecefully, that question which was asked before, so we get a feel of progress [that big close to the chest secret that WCG always seems to want to hold], how many of these 7 bolded digits [below] will change from zero. Each batch is 10,000, in quorum two, 20,000 + assumed error rate, give/take 23-24K submissions to start computing to get 20,000 verified]. One of my devices is processing one now from batch 22, for a possible 9,999,999 which in the extreme means 199,999,980,000 originals (copy _0 +_1). After application of the scientists' heuristics to limit that data to smap, still a gargantuan number, in words 199 billion. Taking there's most always been a spare lead zero on the batch/target numbers, 19 billion :=0

World Community Grid 7.24 mcm1 MCM1_0000022_7638_1 00:38:40 (00:37:06) 95.96 12.346 07:04:59 11/20/2013 4:59:29 AM 11/10/2013 4:59:30 AM Running [0] 00:07:00 84.60 MB desktop-02 43.00 MB

edit: Only now saw a reply by uplinger in another thread "We do not have an estimate of the number of batches."... OK, so FTTB had already plugged 2 years into the Dashboard algorythm. We'll see when we get there... if the first ABCD batches in a years time somehow enable a similar rational as what the DSFL scientists came to do.

Widdershins,

The problem is that since this is a new application, some of the stats used for this type of data was not captured. But the purpose of getting these results back quickly is so the researchers can the results back quickly for analysis.

Also, I believe you can return a work unit up to 24 hours after the deadline and still receive credit if it validates against the canonical result (if that has been found at that point).

I am sorry if you lost time contributing towards this project. Our goal was not to waste CPU time, and as a normal the deadlines are set to 10 days. This batch was set uniquely.

Thanks,
-Uplinger

As it turns out my unit managed to scrape in. It returned before the resend came back, but only just within the 24hrs grace. It looks though that the poor victim who got the resend was, as I half expected, unable to return it within the deadline. Hopefully the unit will linger long enough for the resend to return and get credited also, but as I overran by nearly a day I suspect that with a reduced period to return within the wingman will lose out.

But thanks for clarifying the 24 hr grace period I wasn't aware of that, it's useful to know.

This isn't limited to MCM1 either... I got several CEP2 and FAHV resends, and they all seem to have a 3-day deadline. Which would, again, be only 30% of the original 10 days...