Welcome to the Generalized Fermat Prime Search

This project is LIVE! Please see the second post for previously important Beta information.

This search is for primes of the form b^2^n+1. The numbers F(b,n) = b^2^n+1 (with n and b integers, b greater than one) are called generalized Fermat numbers. In the special case where b=2, they are called Fermat numbers, named after Pierre de Fermat who first studied them.

The original Generalized Fermat Prime Search by Yves Gallot was very active from 2001-2004. It was a premier project ranking second only to GIMPS in organization and size of primes found. In 2009, PrimeGrid, through its PRPNet, revitalized the search thanks in large part to David Underbakke, Mark Rodenkirch, and Shoichiro Yamada, each of whom provided the necessary software updates to get the project moving again. Now with Michael Goetz's native BOINC port of a modified GeneferCUDA, it's time to AWAKEN the potential of this project.

The search will concentrate on N=4194304 (n=22) which, if successful, has the potential of discovering the world's largest known prime number. Due to the size of the work units at this N, this search is a GPU-only project. WUs will get longer with time, but a rough estimate is that one WU will take 8 days to crunch on a GTX 460. Values of b up to approximately 490k are within the testing limits of GeneferCUDA. As of January 2012, a prime found with a b >= 1248 would produce a new world record. (FYI, 1248^4194304+1 is composite. It's not going to be that easy!)

GeneferCUDA is currently only available for Windows and Linux clients. GenefX64 (CPU) is available for MacIntel.

An Nvidia GPU with double precision floating point hardware is required for this project. The following GeForce GPUs will work:



• GTX 260 and above (desktop only; mobile 2xx GPUs do not have double precision)
  
• GTX 4xx
  
• GTX 5xx
  

Many Tesla and Quadro GPUs also will work. They must be CC 1.3 or higher. Check Nvidia's documentation for a comprehensive list.

GeneferCUDA is particularly sensitive to overclocking, and since this project requires 100% correct operation of the entire GPU over an extended period of time, over clocking is not recommended. If you would prefer to crunch smaller WUs and/or use a CPU for crunching, the PRPNet GFN project is seaching at N values of 32768, 65536, 262144, and 524288.

If you have the resources, the drive, and the desire to be the finder of THE LARGEST KNOWN PRIME, then this is your project.

Best of Luck to everyone!!!

----------------------------------------------------------------------------

A search such as this obviously needs a big sieve effort. If you would like to help out with the manual sieving effort, please see the instructions in the GFN Prime Search Sieving thread. It's available for Windows 64 bit CPU's ONLY...but can be run virtually within Linux.

For more information about generalized Fermat numbers and primes, please visit these links:

• Generalized Fermat number - Wikipedia
  
• Generalized Fermat primes - Wikipedia
  
• Generalized Fermat number - Wolfram MathWorld
  
• generalized Fermat number - The Prime Pages
  
• generalized Fermat prime - The Prime Pages
  
• Top 20 Generalized Fermat Primes - The Prime Pages
  

For more information about Fermat numbers and primes, please visit these links:

• Fermat number - Wikipedia
  
• fermat Number The Prime Glossary at the Prime Pages
  
• fermat Number Wolfram Mathworld
  
• fermat Prime Wolfram Mathworld
  

For more information about Pierre de Fermat, please visit these links:

• Pierre de fermat Wikipedia
  
• Pierre de fermat About.com
  

A special thanks to the following people:

• David Underbakke for AthGfn64 (sieve), Genefx64 and updates to Genefer, and Genefer80 used in the PRPNet searches.
  
• Mark Rodenkirch for PRPNet and his collaboration with David in updating Genefx64, Genefer, and Genefer80 to prepare the programs for a distributed effort.
  
• Shoichiro Yamada for GeneferCUDA.
  
• Michael Goetz for the native BOINC build of GeneferCUDA - Windows.
  
• Iain Bethune for the native BOINC build of GenefX64.
  
• Ronald Schneider for the native BOINC build of GeneferCUDA - Linux.
  
  
• and to Everyone who attempts this search. :)
  

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

Special Information Regarding Beta Testing

This project is still in the beta testing phase. There's several differences in the project at this stage, and some additional information you need to know.

• Currently as of 1/22/2012, testing is being done at N=262144. At this size WU, CPU crunching is feasible, and there is a MacIntel CPU client available in addition to the Windows CUDA client.
  
• There is a problem running GeneferCUDA on GTX 550 TI GPUs.
  
  
  
  • The problem is not well understood, and it is unknown if it affects every GTX 500 Ti, or just some of them.
    
  • It's hypothesized that the problem may be related to the unusual "mixed density" memory architecture on this GPU, and if true, that would mean that a small number of other GPUs that also have this architecture might also be affected.
    
  • The problem manifests itself by having WUs fail with "MaxErr Exceeded" errors. This occurs at random times during processing.
    
  • There has been some success with mitigating this problem by lowering the memory clock to 1700 while leaving the core and shader clocks at their normal values.

  
  

• The latest software release (1.05, which should be in production soon, or 1.05 beta 3 which you can run now with app_info) has a tuning parameter that you can set from the PrimeGrid preferences web page. Although initially designed as a tool for dealing with potential screen lag problems, it turns out that you may be able to achieve a small performance improvement using this feature. Please see GeneferCUDA Block Size Setting for more information.

Other known problems:

• There is an intermittent problem with the stderr output that shows up on the result webpage either being truncated or missing. This does not appear to affect the outcome of the WUs, which still get validated correctly.
  
• Screen lag. Like any GPU program, GeneferCUDA has the potential for interfering with the GUI on your computer. At lower N values this isn't usually very severe, although there are some circumstances where it's more intrusive. Certain programs (e.g., Windows Live Mail) or activities (e.g., screen dimming during UAC dialogs), and full-screen video are affected more than others. At least one user has reported extreme lag, at all times, due to GeneferCUDA. It is expected that lag will get worse at higher N values as we move towards full production. It may be necessary to uncheck the "Use GPU when computer is in use" box in the Boinc preferences.
  
• Until just recently, the WUs sent out by the Boinc server had a GFLOPS rating that was too low. This caused bad things to happen to the scheduler in your Boinc client. Now that this has been corrected on the server side, the following steps can correct correct the problem on your client. (assumes you're using Boinc 6.12.34)
  
  
  
  • Shut down the Boinc Client (from the Boinc manager, select Advanced->Shut Down Connected Client...
    
  • Edit the file client_state.xml in your BOINC data directory (Usually C:\ProgramData\BOINC\ under Win7 or Vista). Find the PrimeGrid section in that file. It will start with:
    

    <project>
    <master_url>http://www.primegrid.com/</master_url>

    
    Near the bottom of that section, you will find the DCF line. It looks like this:
    

    <duration_correction_factor>96.273217</duration_correction_factor>

    
    Change the value in there to 1.0, and save the file.
    
  • Restart the client by connecting to the client from the Boinc manager, which will automatically restart the client: Advanced->Select Computer...
    

  The DCF will eventually correct itself, but it will take a long time. This procedure corrects the DCF instantly.
  

• At the present time, GTX 2xx GPUs are not being sent any WUs even though they are CC 1.3. This problem is being worked on.
  

[/b]
____________

Awesome! I've actually been waiting for badges to pop up. I know, I know, it's silly, but... it's fun.

Question: Why does GFN use the same progression (20K, 200K, 1M, 2M, 4M) as sieves rather than the LLR tasks (10K, 100K, 500K, 1M, 2M)? I would think it would use the same progression as all the other Boinc primality projects.

If the answer is "Because it's a GPU project.", then my next question is why does the TRP Sieve use the same progression as the PPS and GSW sieves?

I don't actually care which it is; I'd just like to understand the thinking behind the rules.

Speaking of badges, I'd like to give a shoutout to the folks over at GPUGRID -- I really like what they did with their new badge system. Besides the badges based on the number of credits you've racked up, they also award badges based on the percentile of your contribution to their published papers. That's a nice touch.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

Question: Why does GFN use the same progression (20K, 200K, 1M, 2M, 4M) as sieves rather than the LLR tasks (10K, 100K, 500K, 1M, 2M)? I would think it would use the same progression as all the other Boinc primality projects.

Ah, thanks for the explanation, John. I never knew the reason that sieves had higher goals until today!


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

Can someone give me a rough idea as to current WU runtimes on a stock speed GTX570 and how much credit people are getting per WU at the moment?
Thanks.
____________

35 x 2^3587843+1 is prime!

Just finished my first GeneferCuda on Geforce 560 TI OC version.
Done in 3994 seconds: give me 3600 credits...
____________
92*10^^1585996-1 NEAR-REPDIGIT PRIME :) :) :)
4 * 650^⁴⁹⁸¹⁰¹-1 CRUS PRIME
2022202116^¹³¹⁰⁷²+1 GENERALIZED FERMAT
Proud member of team Aggie The Pew. Go Aggie!

Question: Why does GFN use the same progression (20K, 200K, 1M, 2M, 4M) as sieves rather than the LLR tasks (10K, 100K, 500K, 1M, 2M)? I would think it would use the same progression as all the other Boinc primality projects.

Highly optimized apps deserve higher goals.

In the past, only the sieves offered optimized apps - namely 64 bit vs 32 bit. The GPU optimization came quite a bit afterwards. The first project to benefit was AP26. It was highly optimized over its 32 bit CPU version. It made sense to apply the "higher" badge system then and it still does today.

Yes, llrCUDA is on the horizon, but certainly not as significant of an optimization over 32 bit as other applications. However, this will definitely muddy the waters...but we're not there yet. ;)

Times have changed considerably since the badges were introduced but the spirit of accomplishment remains the same.

If this is the case then how are you calculating credit?

If this is the case then how are you calculating credit?

Google translation into English: "Gee, I wonder what's inside this box? And who is this Pandora person?"

Sorry, John, I couldn't resist. ;-)

I wasn't sure but is this project still a beta project?

So it says in the prefs page. The fact that the project total is not shown on user main pages also points to that beta status...

I know it's still beta but I was noticing that there are many lower end to middle speed cards testing but only 2 570s and one 580 and no 590s unless I missed someone in the threads. All the fastest cards are still on PPS_Sieves and I would think you would want more top cards beta testing so a better incentive might be needed. The current credit is not drawing enough of the big guns in as of now, especially someone with a GTX 590 (or a pair) as there may be unknown issues with those dual chip cards. My example of the different credit for the current n=262144 was merely a suggestion and I know as n increases so will the credit but I was just thinking that getting a baseline ''credits per minute/second/GFlops'' number that will be the production number determined 'now', that then can be used to extrapolate on bigger n's. By doing that now you may draw more fast cards to beta testing. This is all assuming that more fast cards are wanted/needed for testing and eventually longer termed crunching through a higher credit incentive. And as Mike said in another thread that doubling n doesn't translate into doubling WU time. That it's more than double so just doubling 3600 or whatever number when testing goes to 524288 won't work. Any other suggestions that may be helpful? Or is this all a cart before the horse thing?

The question of how credit is determined to begin with, was a serious but curious one. Although, if Pandora's box is how it's done than John or Rytis (or both) must know Pandora pretty well, what with the different sub projects and all. ;)

NeoMetal*

____________
Largest Primes to Date:
As Double Checker: SR5 109208*5^1816285+1 Dgts-1,269,534
As Initial Finder: SR5 243944*5^1258576-1 Dgts-879,713

There's two sides to this credit debate. Well, lots of sides, but consider this counter argument to "You need more credit to draw people off the sieves".

Mind you, this counter-argument is NOT good for PrimeGrid, but it does have a certain appeal for the people who are reading this board.

One of us is possibly going to be the world record holder in the not so distant future. This person may end up holding that record for more than a few years.

Would you rather that person be someone who is interested in finding primes, or someone whose only interest was in getting to the top of the credit leader board?

Now, of course, the goal is for SOMEONE to find it, and the odds of that happening goes up with more people crunching. And do not forget that this IS a race and speed is very important: I'm not certain where GIMPS is searching right now, but if they find another Mersenne before we find a GFN at N=4194304, their new prime may be above what we can find at that N. So we have a window of opportunity here, and that window might close.

So, that's my counter-argument AND my counter-counter-argument. :)
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

How do I go about running the genefercuda part, I've tried connecting to the servers but it says something along the lines of no work is available, maybe I've configured it totally wrongly but it appeared to be working for the other parts I tried, PPS & SGS.

It also prompts me that cudart_32_32_16.dll is missing, should I just download this and retry?

Apologies, I was trying via the prpclient-5.0.4 command line, in BOINC I don't see the option to subscribe, probably because I haven't requested it.

How do I request to get it added or do I just add the lines to the app info file, and if so what would the lines be?

Cheers

Does the due date have to be so short (~24 hours)? If your queue size is set to anything greater than 1 day, it over-downloads. (Yes, I already checked my DCF, it is currently 1.1.)
____________
Reno, NV

Does the due date have to be so short (~24 hours)? If your queue size is set to anything greater than 1 day, it over-downloads. (Yes, I already checked my DCF, it is currently 1.1.)

Does the due date have to be so short (~24 hours)? If your queue size is set to anything greater than 1 day, it over-downloads. (Yes, I already checked my DCF, it is currently 1.1.)

Sorry, this is still beta testing for now. Once the project goes live, the deadline will be adjusted accordingly.

Any chance for an OSX CUDA app?
____________
Reno, NV

are you planning to add a section for the sub-project gfn under a users home screen.
e.g. where you see how many tasks you computed, how many credits for this subproject and where you can click on your prime-list etc?

____________

GeneferCUDA is sensitive not only to overclocking, but also to temperature under overclocking. My card receives an error more than ~82C, but at 75C WU run stable. link to image

are you planning to add a section for the sub-project gfn under a users home screen.
e.g. where you see how many tasks you computed, how many credits for this subproject and where you can click on your prime-list etc?

• The badges are in.
  
• The stat export is in, so GFN shows up on the free-DC sub-project stats.
  
• The application page lists the Genefer applications.
  
• EVERYTHING necessary to make GFN actually work! :)
  

I think this is the only remaining part to go, and it will be done.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

As always, take your time. I'd rather have an app that works (damn near) perfectly without stats than stats and a borked app that wastes my C/GPU time! :)

If temperature affects the results, then it's not a software problem. The sensitivity to overclocking is definitely a hardware issue.

One mystery solved.

Again, thanks.

are you planning to add a section for the sub-project gfn under a users home screen.
e.g. where you see how many tasks you computed, how many credits for this subproject and where you can click on your prime-list etc?

The project's still in beta. Slowly, they've been adding in all the webserver parts:

• The badges are in.
  
• The stat export is in, so GFN shows up on the free-DC sub-project stats.
  
• The application page lists the Genefer applications.
  
• EVERYTHING necessary to make GFN actually work! :)
  

I think this is the only remaining part to go, and it will be done.

are you planning to add a section for the sub-project gfn under a users home screen.
e.g. where you see how many tasks you computed, how many credits for this subproject and where you can click on your prime-list etc?

The project's still in beta. Slowly, they've been adding in all the webserver parts:

• The badges are in.
  
• The stat export is in, so GFN shows up on the free-DC sub-project stats.
  
• The application page lists the Genefer applications.
  
• EVERYTHING necessary to make GFN actually work! :)
  

I think this is the only remaining part to go, and it will be done.

Rytis added GFN stats to account page. :)

• Add GFN to the Subprojects status page.
  
• Primes need to be added to the Top Prime Finders list.
  
• Submission of primes to the top 5K list.
  

The first two I forgot because those pages are currently disabled for the challenge. They may, in fact, already be done.

The third is something out of sight, and it may probably already done.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

I think you are all doing a wonderful job but I have a question.

I am never one to complain about getting too many wus LOL but I am getting way to many wus to do in the time given to do them, so I changed my computing preferences for 1 days of work and it is not working. I got 49 wus to do by 8:17:29 tomorrow night. I have lots of others to do before that.

My GPU is a GTX560, I am averaging around 20 wus a day and I have Vista if that helps.

Is there anyway of controlling the amount of wus I am getting? I really hate to abort them because I can't do them in time.

Thank you for your time in answering ~smiles~

And if( for now) WU on my card is need 58 Min to be finished, and I got 3600 credits for one: how many will I get for WU that will be few times longer?
____________
92*10^^1585996-1 NEAR-REPDIGIT PRIME :) :) :)
4 * 650^⁴⁹⁸¹⁰¹-1 CRUS PRIME
2022202116^¹³¹⁰⁷²+1 GENERALIZED FERMAT
Proud member of team Aggie The Pew. Go Aggie!

(We're currently at n=18. At n=19, the WUs are about 3 times longer, and at n=20, they're about 12 times longer. Our eventual target is n=22, where the WUs are 130 to 250 times longer.)

I think we're ready to move up to n=20 -- and the deadlines will have to be longer for that. With longer deadlines, you can make your buffers larger and Boinc will be able to handle it.

Are we just going to jump right over n=19 or do you just mean that the project is debugged enough to be able to move to n=20?

There is a reason to stay at n=18, however: with all the GPU power available on the Boinc side, there's a possibility for finding some nice primes during the Tour de Primes. The winner of the green jersey this year, in my opinion, will probably be someone using a GPU crunching GFN at n=18.

There is another reason to stay at n=18 for a while longer...we are not quite finished with sieving for n=20,21,22.

On the debugging process, looking at my wingman results, I keep seeing a lot of tasks aborted (probably due to DCF issues), but also a high rate of "errors while computing" and "marked as invalid". This may be acceptable with tasks that take less than two hours on a low end card, but might mean a big waste of crunching power at higher n.

The positive side is that most "errors while computing" seem to happen at the beginning (looking at reported times) and are mush more frequent than invalid tasks (by other causes). My sample is small though. Not sure if it represents the whole Genefer-Boin universe.

I have alot of errored units. It doesn't show my which card ran the unit, but I suspect it's the 8800 and not the 460 that is having the errors. I don't recall any errors before adding in the 8800 for testing it out since I got it used. It's not only these units I'm seeing errors on, the gpu tasks for MilkyWay also have been erroring out since adding the 8800.

Is there a way to set the units to check if the card is compatible before trying to run it? It won't be an issue for me much longer, waiting on a few more pieces to come in for a new system and the 8800 is going in that, but for those who are running more than one card with a possible incompatible card....

Priority change succeeded.
GPU=GeForce 8800 GT
Global memory=511377408 Shared memory/block=16384 Registers/block=8192 Warp size=32
Max threads/block=512
Max thread dim=512 512 64
Max grid=65535 65535 1
CC=1.1
Clock=1500 MHz
# of MP=14
A GPU with compute capability >= 1.3 is required for this program.

<exclude_gpu>

Don't use the given GPU for the given project. If <device_num> is not specified, exclude all GPUs of the given type. <type> is required if your computer has more than one type of GPU; otherwise it can be omitted. <app> specifies the short name of an application (i.e. the <name> element within the <app> element in client_state.xml). If specified, only tasks for that app are excluded. You may include multiple <exclude_gpu> elements. New in 6.13
<exclude_gpu>
<url>project_URL</url>
[<device_num>N</device_num>]
[<type>nvidia|ati</type>]
[<app>appname</app>]
</exclude_gpu>

I'll try it out when I get a chance, right now, I'm just going with having another gpu application sending work, since the 460 is faster than the 8800, it picks up these before the 8800 has a chance, since the 8800 runs the longer GPUGrid tasks in about 24-30 hours....

Its not perfect, but it ensures the 8800 isn't always running and erroring a Genefer task....

And if it helps with anything, my 460 hasn't errored any units and its oc'd to 865/1730/1950 and voltage set at 1 v.... it stays a constant 68C crunching a genefer unit with the fan at 90%....

are you planning to add a section for the sub-project gfn under a users home screen.
e.g. where you see how many tasks you computed, how many credits for this subproject and where you can click on your prime-list etc?

The project's still in beta. Slowly, they've been adding in all the webserver parts:

• The badges are in.
  
• The stat export is in, so GFN shows up on the free-DC sub-project stats.
  
• The application page lists the Genefer applications.
  
• EVERYTHING necessary to make GFN actually work! :)
  

I think this is the only remaining part to go, and it will be done.

Rytis added GFN stats to account page. :)

I just realized I forgot one (make that two, um, three...) item(s) from my list:

• Add GFN to the Subprojects status page.
  
• Primes need to be added to the Top Prime Finders list.
  
• Submission of primes to the top 5K list.
  

The first two I forgot because those pages are currently disabled for the challenge. They may, in fact, already be done.

The third is something out of sight, and it may probably already done.

And if it helps with anything, my 460 hasn't errored any units and its oc'd to 865/1730/1950 and voltage set at 1 v.... it stays a constant 68C crunching a genefer unit with the fan at 90%....

are you planning to add a section for the sub-project gfn under a users home screen.
e.g. where you see how many tasks you computed, how many credits for this subproject and where you can click on your prime-list etc?

The project's still in beta. Slowly, they've been adding in all the webserver parts:

• The badges are in.
  
• The stat export is in, so GFN shows up on the free-DC sub-project stats.
  
• The application page lists the Genefer applications.
  
• EVERYTHING necessary to make GFN actually work! :)
  

I think this is the only remaining part to go, and it will be done.

Rytis added GFN stats to account page. :)

I just realized I forgot one (make that two, um, three...) item(s) from my list:

• Add GFN to the Subprojects status page.
  
• Primes need to be added to the Top Prime Finders list.
  
• Submission of primes to the top 5K list.
  

The first two I forgot because those pages are currently disabled for the challenge. They may, in fact, already be done.

The third is something out of sight, and it may probably already done.

Also 'Pending credits' page doesn't support GFN.

Yes it does. Just the amount of credit that's pending is borked. But that's always the case with work units for which you always get the same amount of credits.

And if it helps with anything, my 460 hasn't errored any units and its oc'd to 865/1730/1950 and voltage set at 1 v.... it stays a constant 68C crunching a genefer unit with the fan at 90%....

I've also got a 460, but I run it at stock (1350). 1730 is... a lot faster!

Last night I clocked my card to 1630. Everything ran hotter, and faster. That cut 15 to 20 minutes off the WU.

With the big WUs, overclocking like that will mean cutting a day or more off the run time. Very tempting -- but I probably still won't do it and opt for an extra margin of stability.

Any chance for an OSX CUDA app?

Thanks for the response. At the time I asked, I was considering upgrading my Mac Pro to a GTX 285. But I have since learned that my 2006 vintage does not support it. Ah well.
____________
Reno, NV

I have a GTX590 and just crunched a couple of WU's.
The card is stock and the runs times were 3285 seconds.
Are these times ok?... The block size is set to zero.