GPU to 72 status... - Page 138

garo · 2012-10-03, 08:58

I remember there was a link to James' analysis on optimal GPU TF bit levels somewhere. Is this it? And why then do the colors change at 150 and 300? Shouldn't they change at 100 and 200? Or taking LL errors into account, 105 and 210?

LaurV · 2012-10-03, 09:13

Assuming you talk about red/green table on the top (from your link, one has to click on any card he likes, then he gets the table), then yes, they DO break at 100 and 200. Or..hmm...well... at the closest possible of those...

Everything seems ok for me.

James Heinrich · 2012-10-03, 13:25

Quote:

Originally Posted by garo

why then do the colors change at 150 and 300? Shouldn't they change at 100 and 200? Or taking LL errors into account, 105 and 210?

Looking at a more specific example (doesn't matter much which GPU, I picked GTX 580 @ 1M granularity).

The cutoff points are 100% and 200%, but the chance of exactly "100" and/or "200" showing up on the graph is slim (out of 56 rows in the above example, only 46M and 74M come up exactly (after rounding) on "100", but even then don't hit "200" (actually 204, 202). So, to guarantee that one box is always coloured appropriately, I'm mapping anything in (0.75 < x < 1.50) as "100%", and (1.50 < x 3.00) as "200%". Due to the doubling nature of each successive column, only one column for any row will match the "100%" and "200%" colour range (although it's possible that it will miss a match, such as on 49M: 150/303).

The whole issue is the rasterization of a curve. I could antialias the colours in the table, or present the whole thing as a image graph and it would appear less stepped.

garo · 2012-10-04, 08:51

I see your point about needing to decide on some threshold. I was reading the graph vertically to determine appropriate cutoffs for each bit level. It probably makes more sense to read it horizontally to determine the optimal bit level for each range.

James Heinrich · 2012-10-04, 11:54

Quote:

Originally Posted by garo

I was reading the graph vertically to determine appropriate cutoffs for each bit level.

Look at the far-right column, which is the the cutoff for 2 LL tests.

garo · 2012-10-04, 17:07

Quote:

Originally Posted by James Heinrich

Look at the far-right column, which is the the cutoff for 2 LL tests.

Oh! Silly me. Thanks for that.

ckdo · 2012-10-05, 07:15

Quoting Firefox:

www.gpu72.com uses an invalid security certificate.

The certificate is not trusted because it is self-signed.
The certificate is only valid for Parallels Panel
The certificate expired on 13.08.2012 12:17. The current time is 05.10.2012 09:10.

OTOH, gpu72.com returns "Page not found!" on all requests anyway ATM...

Uncwilly · 2012-10-05, 08:02

Quote:

Originally Posted by ckdo

OTOH, gpu72.com returns "Page not found!" on all requests anyway ATM...

It is fine here right now.

nucleon · 2012-10-05, 22:57

Any stats on 72-73 range for factors? How does current discovered ratio map to theoretical predictions.

For me, I'm finding 72-73 pretty bare (factor-wise).

-- Craig

chalsall · 2012-10-05, 23:04

Quote:

Originally Posted by nucleon

Any stats on 72-73 range for factors? How does current discovered ratio map to theoretical predictions.

For me, I'm finding 72-73 pretty bare (factor-wise).

-- Craig

The best I can provide is https://www.gpu72.com/reports/factor_percentage/.

Overall, 72 -> 73 is providing a 1.285% success rate. Slightly better than expected.

kladner · 2012-10-05, 23:52

Quote:

Originally Posted by chalsall

The best I can provide is https://www.gpu72.com/reports/factor_percentage/.

Overall, 72 -> 73 is providing a 1.285% success rate. Slightly better than expected.

I seem to run 8-10 factors behind prediction. Currently 91.717 predicted, 82 found. On the other hand, when I was doing DCTF I had 7.567 predicted and 16 found. There are bound to be ebbs and flows, aside from the required effort increasing for each level. Taking longer for each level makes the found factors seem more sparse.

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

2012-10-03, 08:58	#1508
garo Aug 2002 Termonfeckin, IE 2²·691 Posts	I remember there was a link to James' analysis on optimal GPU TF bit levels somewhere. Is this it? And why then do the colors change at 150 and 300? Shouldn't they change at 100 and 200? Or taking LL errors into account, 105 and 210?

2012-10-03, 09:13	#1509
LaurV Romulan Interpreter Jun 2011 Thailand 25BF₁₆ Posts	Assuming you talk about red/green table on the top (from your link, one has to click on any card he likes, then he gets the table), then yes, they DO break at 100 and 200. Or..hmm...well... at the closest possible of those... Everything seems ok for me.

2012-10-04, 08:51	#1511
garo Aug 2002 Termonfeckin, IE 5314₈ Posts	I see your point about needing to decide on some threshold. I was reading the graph vertically to determine appropriate cutoffs for each bit level. It probably makes more sense to read it horizontally to determine the optimal bit level for each range.

2012-10-05, 07:15	#1514
ckdo Dec 2007 Cleves, Germany 2×5×53 Posts	Quoting Firefox: www.gpu72.com uses an invalid security certificate. The certificate is not trusted because it is self-signed. The certificate is only valid for Parallels Panel The certificate expired on 13.08.2012 12:17. The current time is 05.10.2012 09:10. OTOH, gpu72.com returns "Page not found!" on all requests anyway ATM...

2012-10-05, 22:57	#1516
nucleon Mar 2003 Melbourne 5·103 Posts	Any stats on 72-73 range for factors? How does current discovered ratio map to theoretical predictions. For me, I'm finding 72-73 pretty bare (factor-wise). -- Craig