The short GFN tasks (n=19 or N=524288) are currently at around b=660K. Work is loaded up to b=700K.

We expect the CPU-based GenefX64 program to start to fail around b=735K, so at b=700K we will shift to n=20 (N=1048576) for the short tasks. This will likely occur within the next 4 to 8 weeks.

Once that shift occurs, you can expect the short tasks to initially run about twice as long as they do today. Within a few months, as b increases, run times will gradually increase until they are about 4 times as long as they are today.

Once we start crunching n=20 on BOINC, we will restart n=19 on PRPNet, where you can continue to crunch on either the CPU or GPU. Expect the CPU crunching to shift to Genefer80 at around b=735K. That will increase the processing time of each WU by a factor of about 3x. GPU crunching can continue until about b=815K, at which point the crunching will also need to shift to Genefer80.


____________
My lucky number is 75898⁵²⁴²⁸⁸+1

UPDATE 19-Nov: The leading edge is now at 680K. The switch to n=20 will likely occur within the next week; two weeks at most.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

UPDATE 19-Nov: The leading edge is now at 680K. The switch to n=20 will likely occur within the next week; two weeks at most.

The sieving effort for n=20 is still going on, right?

Yep, there's still about 8000P left to be sieved to reach the target.

Just moved a gpu there. I hope that that move will not make me miss a prime on the last 20k left t crunch on Boinc :)

By the way, how do the nvidia 6xx series behave there? are they faster or slower than previous series?

I don't own one, so I can't say from experience, but I would expect it to be substantially faster than the 5xx series. It's only double precision apps, like Genefer, that suffer on the Kepler GPUs.

n=19 leading edge has reached (and stopped growig) 700k a few day ago.
Has n=20 already been loaded (no info on that on se subproject status page)? If not, when will it be?

Thanks in advance

UPDATE: N=19 leading edge is now 694896. 841 WUs to go.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

UPDATE: n=19 leading edge is now 698318. 282 WUs to go.

The last WU should be sent out in the next 24 hours. After that, it's just waiting for the results to come back in and issuing resends for tasks that return errors.

____________
My lucky number is 75898⁵²⁴²⁸⁸+1

N=20 tasks are now being sent out. N=19 tasks, mostly resends, will also continue to be sent out until all of the 524288 work units are completed and verified.

N=20 tasks currently have a deadline of 15 days, although some of the earliest may have a deadline of 11 days. The very smallest of these tasks are actually shorter than the old n=19 tasks, but most will be larger. The longest n=20 sent out so far is about 60% longer than the n=19 tasks (about 9 hours on my GTX 460 vs 5.5 hours for the old tasks.) This will rapidly increase to about 2.5 to 3 times as long as the old tasks over the next couple of days.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

The very smallest of these tasks are actually shorter than the old n=19 tasks, but most will be larger.

The very smallest of these tasks are actually shorter than the old n=19 tasks, but most will be larger.

Any b < sqrt(700000) = 836 would be redundant since it would have been tested as part of n = 19. :(

[eg:- 6^1048576 = 36^524288]

Any b < sqrt(700000) = 836 would be redundant since it would have been tested as part of n = 19. :(

[eg:- 6^1048576 = 36^524288]

Has the "default block size" (what one gets by specifying 0 on the PG preferences page) been changed for optimal performance for n=20 (vs 19)? It looks like from stderr.txt it has changed from 7 to 8. Just wanted to confirm I'm not misconfigured somehow.

--Gary

Any b < sqrt(700000) = 836 would be redundant since it would have been tested as part of n = 19. :(

[eg:- 6^1048576 = 36^524288]

And we could intentionally test some high b's above CUDA limits for n=19 using n=20, right?

Has the "default block size" (what one gets by specifying 0 on the PG preferences page) been changed for optimal performance for n=20 (vs 19)? It looks like from stderr.txt it has changed from 7 to 8. Just wanted to confirm I'm not misconfigured somehow.

--Gary

Have enough n=20 units been run to give out average run times by card?

Assuming that we do find at least one prime with N=1048576, where would such a prime rank in the overall list?

As of today, the 4 known primes at N=524288 rank in positions 16, 13, 12, and 11 on the all time largest prime list.

Primes with N=1048576 would rank as follows:

(There may appear to be gaps in the number sequences below, for example, b=10. That's because the missing numbers were removed by sieving.)

• b <= 8 have less than 1 million digits, and are the only two candidates that would not be mega-primes if they were indeed prime.
  
  
• 12 <= b <= 272 would be lower than 16th place on the list, i.e., smaller than all of the N=524288 primes.
  
  
• 276 <= b <= 418 would be the 16th largest prime number.
  
  
• 430 <= b <= 584 would be the 14th largest prime number. (15 and 14 are so close together so there are no remaining candidates that are larger than 15 but smaller than 14.)
  
  
• 586 <= b <= 596 would be the 13th largest prime number.
  
  
• 618 <= b <= 684 would be the 12th largest prime number.
  
  
• 692 <= b <= 5462 would be the 11th largest prime number.
  
  (Note that, as axn mentioned above, all b <= 836 are already known to be composite due to work done on N=524288. Therefore, the lowest possible prime we will find with N=1048576 will rank 11th on the list.)
  
  
• 5464 <= b <= 7332 would be the 10th largest known prime.
  
  
• 7350 <= b would rank 9th on the list.
  

____________
My lucky number is 75898⁵²⁴²⁸⁸+1

I think GFN n=20 (cpu version) is now (or will be very soon) the longest sub-project on Primegrid (longer than SoB).

C:\PRPNet\prpclient-5.0.8-windows-gpu\prpclient-2-gpu>llr64 -d -q"67607*2^20905411+1"
Starting Proth prime test of 67607*2^20905411+1
Using all-complex FFT length 1920K, Pass1=384, Pass2=5K, a = 3
67607*2^20905411+1, bit: 10000 / 20905427 [0.04%]. Time per bit: 38.210 ms.

C:\PRPNet\prpclient-5.0.8-windows-gpu\prpclient-2-gpu>genefx64 -q "600000^1048576+1"
...
Estimated total run time for 600000^1048576+1 is 267:32:17

I bet the limit will be reached before the end of 2013 (unless NASA is wrong about the end of the world in a fortnight... ).
My last SoB took 75 hours (with AVX). Genefer does not benefit from AV . Leading edge would take ~70 hours on my rig.

After looking thru the candidates in http://home.comcast.net/~jimb_primegrid/guess20.txt, I've identified the following 15 candidates that can be removed from consideration:

axn, would you mind explaining in one-syllable words why the following candidates should be removed?

I'll use zero-syllable words :)

(a^b)^c = a^(bc) = (a^c)^b

7776^1048576+1 = (6^5)^1048576+1 = (6^1048576)^5+1

x^n+1 is divisible by x+1 if n is an odd integer. (This is the reason behind all GFNs having perfect power of 2's as their exponent)

Therefore, (6^1048576)^5+1 is divisible by 6^1048576+1.

Likewise, for others.

EDIT:- This is actually the reason for nominating 2^17 and 2^19 as well.

Thinking about all this, I've finally written a few programs to find candidates that could be eliminated for various reasons. I will be removing these candidates from the corresponding sieves in the next day or so.

Candidates like the ones axn explained above can be found here. I'm only listing items not already eliminated by sieving, otherwise this list would be a lot longer.

Candidates that can be eliminated because of prime-testing at n=22 can be found here. Only about half the n=21 candidates could be removed right now, but by the time we start prime-testing there, n=22 will be far past b=10K. The "in sieve" or "removed" part refers to the n=22 sieve. If the number had been removed from the lower n sieve, it doesn't appear at all.

If there are any other methods of eliminating candidates, I"m interested in hearing about them.

These can be removed because they're (known composite) Fermat numbers:

256^524288+1 = 16^1048576+1 = 4^2097152+1 = 2^4194304+1 (F22: known factor 3853959202444067657533632211*2^24+1)

65536^1048576+1 = 256^2097152+1 = 16^4194304+1 [ = 4^8388608+1 = 2^16777216+1 ] (F24: proven composite with Pepin's test)

Their status can be found here: http://www.prothsearch.com/fermat.html



Also, when n=21 starts testing, we can remove from consideration, all b < sqrt(600000) [ b limit for n=20] using the 20-21 equivalence.