[QUOTE=Aramis Wyler;338064]I thought we were going to be done with it.[/QUOTE]

We will. In about 2020....

[QUOTE=chalsall;338066]We will. In about 2020....[/QUOTE]
...unless more people do it.

[QUOTE=kracker;338068]...unless more people do it.[/QUOTE]

Always an option with free agents....

[QUOTE=kracker;338068]...unless more people do it.[/QUOTE]

Buy more GPUs...

[QUOTE=davieddy;338085]Am I the only one who considers this to be a more exciting milestone?[/QUOTE]Imagine how exciting finding a 100M digit prime would be. And imagine how rewarding it might be.

Yeah, I could use the bucks. I think once we get p-1 running well on gpus I'll set my cpus to doing LL work again. Maybe in the 332M range.

[QUOTE=Aramis Wyler;338047]Is that 2,209 days to doublecheck the LL? Surely not to finish the DCTF?

[SIZE=1](or if it is, why does the [/SIZE][URL="http://www.gpu72.com/reports/estimated_completion/"][SIZE=1]chart[/SIZE][/URL][SIZE=1] say 99?)[/SIZE][/QUOTE]
I realize this has been answered, but it's one of those things that I kinda disliked but never brought up.

The chart is accurate in 1 respect saying 99 days... *IF* everything using GPU72 were to run DCTF, in 99 days it would be done. The 2209 seems to be "At the rate we currently have people doing DCTF" which is more reliable. Being the defacto 'top dog' in DCTF, I've always known that the 'estimate' was way off, but knew why and never commented.

Actually. it's more like one report dealing only with exponents held by GPU72 at present and the other including those not (yet) held by GPU72...

[QUOTE=bcp19;338160]The chart is accurate in 1 respect saying 99 days... *IF* everything using GPU72 were to run DCTF, in 99 days it would be done.[/QUOTE]

Not any longer. Both reports now calculate the estimates based on the individual work types. As in, the LLTF estimates are now based solely on the last 30 days of LLTF work done; the DCTF estimates are solely based on the DCTF work done.

As ckdo points out, the first report is showing the estimates for everything we "own" (read: have reserved from Primenet). The second report is the estimates for everything based on the candidate status (as in, LL candidates or DC candidates; a candidate with a successful DC does not get included in either table).

an observation and a thought
 

I notice that when I select P-1 in the DC range it determines only 1.1 LL tests saved and with that will pick lower B1/2 and run faster.
Makes sense to spend less P-1 time with less potential savings.

So that made me wonder if the same logic makes sense for DC-TF.
It a factor found in that range only saves 1 LL test should the TF depth be maybe 1 bit less than what it should be if the same exponent was being factored for LL

Or conversely should DC P-1 use 2 LL tests saved to improve the odds of saving the DC?

[QUOTE=petrw1;338297]Makes sense to spend less P-1 time with less potential savings.
So that made me wonder if the same logic makes sense for DC-TF.[/QUOTE]That logic (~1-bit lower TF for DC) can be seen on the graphs here: [url]http://www.mersenne.ca/cudalucas.php?model=9[/url]

And I'm pretty sure that's already part of the GPU72 assignment strategy.

[QUOTE=petrw1;338297]Or conversely should DC P-1 use 2 LL tests saved to improve the odds of saving the DC?[/quote]You could use 10 tests saved to improve the odds even further, but the overall idea is to make most [i]efficient[/i] use of computing resources to clear exponents. Spending more time on TF and/or P-1 will find more factors, but the optimal balance of factoring effort vs probability will clear exponents (either by factor or by two matching LL tests) fastest.