GPU to 72 status... - Page 200

chalsall · 2013-04-23, 22:10

Quote:

Originally Posted by Aramis Wyler

I thought we were going to be done with it.

We will. In about 2020....

kracker · 2013-04-23, 22:24

Quote:

Originally Posted by chalsall

We will. In about 2020....

...unless more people do it.

chalsall · 2013-04-23, 22:35

Quote:

Originally Posted by kracker

...unless more people do it.

Always an option with free agents....

Chuck · 2013-04-24, 00:26

Quote:

Originally Posted by kracker

...unless more people do it.

Buy more GPUs...

Uncwilly · 2013-04-24, 02:40

Quote:

Originally Posted by davieddy

Am I the only one who considers this to be a more exciting milestone?

Imagine how exciting finding a 100M digit prime would be. And imagine how rewarding it might be.

Aramis Wyler · 2013-04-24, 02:54

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.

bcp19 · 2013-04-24, 19:44

Quote:

Originally Posted by Aramis Wyler

Is that 2,209 days to doublecheck the LL? Surely not to finish the DCTF?

(or if it is, why does the chart say 99?)

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.

ckdo · 2013-04-25, 05:12

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...

chalsall · 2013-04-25, 13:56

Quote:

Originally Posted by bcp19

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.

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).

petrw1 · 2013-04-25, 19:06

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?

James Heinrich · 2013-04-25, 19:12

Quote:

Originally Posted by petrw1

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.

That logic (~1-bit lower TF for DC) can be seen on the graphs here: http://www.mersenne.ca/cudalucas.php?model=9

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

Quote:

Originally Posted by petrw1

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

You could use 10 tests saved to improve the odds even further, but the overall idea is to make most efficient 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.

2013-04-25, 19:06	#2199
petrw1 1976 Toyota Corona years forever! "Wayne" Nov 2006 Saskatchewan, Canada 2²×3×17×23 Posts	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?

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Status	Primeinator	Operation Billion Digits	5	2011-12-06 02:35
62 bit status	1997rj7	Lone Mersenne Hunters	27	2008-09-29 13:52
OBD Status	Uncwilly	Operation Billion Digits	22	2005-10-25 14:05
1-2M LLR status	paulunderwood	3*2^n-1 Search	2	2005-03-13 17:03
Status of 26.0M - 26.5M	1997rj7	Lone Mersenne Hunters	25	2004-06-18 16:46

2013-04-24, 02:54	#2195
Aramis Wyler "Bill Staffen" Jan 2013 Pittsburgh, PA, USA 2³·53 Posts	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.

2013-04-25, 05:12	#2197
ckdo Dec 2007 Cleves, Germany 2×5×53 Posts	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...