Project status

GFN-14 search finished 10 Jan 2021. All candidates up to b=400M were tested, finding or confirming total of 10304 primes.

Project description

Some time ago, PrimeGrid discovered an interesting beast - a pair of consecutive GFN-15 primes. Numbers 87888966^32768+1 and 87888968^32768+1 are both primes. Such numbers form an OEIS sequence A118539. Early, only numbers up to GFN-12 were known. Quickly we discovered that our GFN-13/14 prime search also found not only one, but two GFN-13 pairs: 103859114/103859116 and 111359046/111359048! But...

There are no such pair known for GFN-14 yet. Therefore, a hunt for GFN-14 consecutive pair is open!

How it works

We'll use our existing private GFN-13/14 server. The change is almost transparent to existing users. Early we've tested all possible candidates sequentially, to find all possible primes from 0 to upper software limit. Now only one candidate from a group - consecutive pair or triplet - will be loaded into the system. If candidate becomes composite, it'll cancel whole group. If it happens to be a prime, it's neighbors will also be loaded into the system for additional testing.

We will test candidates from 22M (not loaded yet into the system) to 400M (Genefer GPU software limit) until we find a pair or reach end of the range. There are about 7,000,000 candidates to test. Tasks are very small (less then minute on GPU, 5-15 minutes on CPU), so, with active participation, whole range could be tested in few months. It's also possible that we'll find such pair tomorrow. It's a question of luck, like on conjectures. After end of the hunt, server will be returned to standard sequential search mode for all remaining candidates.

Tasks are available for CPU and GPU for all major platforms. CPU tasks has lower limit (currently estimated about 100M) and will be disabled near this point.

How to participate

To participate, please register at GFN-13/14 Boinc server at http://boincvm.proxyma.ru:30080/test4vm/

- Go to URL above;

- Click on "Your account" on left panel;

- Click on the "or create an account" link in the bottom left part of the page;

- In the "Invitation Code" field, enter PrimeGrid

- Fill other fields in usual way. It's preferred to use same email address as on PrimeGrid, it's required for possible transfer of credit (if it ever happens, see below).

- After registration, connect your Boinc client to the project using URL above. It's recommended to use "weak account key" in place of of true password. Your can get your key on "Your account" page, click on "Account keys"

For new users, your account will be automatically configured to work on GFN-14 project with GFN-13 project as backup (in case of temporary shortage of work). Existing users should manually select GFN-14 project, disable GFN-13 and enable "If no work for selected applications is available, accept work from other applications?" option if they like to keep GFN-13 as backup project.

The server is compatible with PrimeGrid and supports extra venues (Sun...Pluto). Note: this is not a PrimeGrid server. Although all discussion and support happens here on PrimeGrid forum, the server is running on my own resources.

Schedule

There is no specific start time. Instead, the hunt starts as soon as leading edge reaches 22M. There are some "standard" canidates from 21M to 22M which can be used to test and tune your systems. Time required to purge these candidates is unpredictable and strongly depends on participation level, it can be anywhere from 2 to 7 says.

Optimizing performance

CPU - it seems that hyperthreading improves overall performance, at least on Intel CPUs.

GPU - First, check GPU usage (using free tool GPU-Z on Windows or NVIDIA control panel on Linux). If GPU usage is less then 70-80%, you have to configure your system to run few tasks at once, otherwise modern GPUs will not be fully utilized.

Second, you MUST keep one CPU core free to feed GPU. Unfortunately, Genefer requires significant amount of CPU time for low GFNs (not a full core, but still noticeable). Hypethreading helps here, one hypethread core is more then enough for this.

To limit number of CPU cores, use your Boinc client configuration dialog. Also you can manually create cc_config.xml file in the Boinc data directory. Example:

Great idea - out of interest, how what fraction of the candidates that pass (normal) sieving are consecutive? i.e. how much faster will this search proceed than the normal GFN prime search?

- Iain
____________
Twitter: IainBethune
Proud member of team "Aggie The Pew". Go Aggie!
3073428256125*2^1290000-1 is Prime!

Great idea - out of interest, how what fraction of the candidates that pass (normal) sieving are consecutive? i.e. how much faster will this search proceed than the normal GFN prime search?

Yay!

It would be most fun (and april spirit), if we find a consecutive pair in the normal 21M candidates before the hunt.

P.S. Based on benchmarks that I run when first joined the private server, I'm using -x ocl5 for gfn14 gpu tasks rather than ocl4.
P.P.S. This is "old" ocl4, by the way, known as ocl2 in current versions of genefer. The project uses an older genefer v.3.3.1. You can try using a newest version with app_info.xml, but in my experience (again, running the benchmarks with numbers from the project), genefer331 is tiny bit faster on these numbers.
P.P.P.S. Genefer employs the GPU fully while running, but running multiple GPU tasks at the same time deals with the downtime between previous task spinning down and the next one spinning up. Since the length of the tasks can be <30 sec, the 5-7 sec of that downtime is worth filling by a parallel task, if you're maximizing throughput.

However I am having heat problems with CPU tasks and I don't find an option not to use CPU.
So, in the example xml file you gave us, which line needs to be modified to run 1 CPU only.
Is it possible to exclude CPU usage?

Leading edge just passed 22M, first twin candidates are sent to clients. The hunt is open! Good luck everyone!

Is there a way to check if I have discovered any primes, pairs or otherwise?
____________
Long live the sievers.

+ Encyclopaedia Metallum: The Metal Archives +

Is there a way to check if I have discovered any primes, pairs or otherwise?

Cool, thanks.
____________
Long live the sievers.

+ Encyclopaedia Metallum: The Metal Archives +

But specially for this hunt, I will make an online statistic page (it will be automatically updated daily). It should take 2-3 days, I'm not a PHP/HTML expert at all. I'll post here once it's ready.

This good news, thank you stream, looking forward to it.

408 error happening again, is there something wrong?

P.S. Based on benchmarks that I run when first joined the private server, I'm using -x ocl5 for gfn14 gpu tasks rather than ocl4.
P.P.S. This is "old" ocl4, by the way, known as ocl2 in current versions of genefer. The project uses an older genefer v.3.3.1. You can try using a newest version with app_info.xml, but in my experience (again, running the benchmarks with numbers from the project), genefer331 is tiny bit faster on these numbers.

Well, I made simple statistic page to start with. Check it out (also there is a link from main project page). Data is updated every 6 hours.

On statistic page, you can now click on user name to see your discovered primes, if anybody interested.

>
It's a good idea to crunch something even if project server has temporary gone offline. Go to PrimeGrid Preferences page and set "Resource Share" to 0. If GFN server becomes out work or unreachable, your Boinc client will automatically switch to PrimeGrid tasks until GFN server recovers.

I assume you mean to set PrimeGrid Resource Share to 0

Correct?

Based on current progress, a rough estimate to run all the candidates is about 76 days from now (finishing on June 29th).

Although, hopefully, we will find the one long before the end. With the same estimation, the middlepoint falls on May 22nd. My bet is: end of may (last two weeks) is when we find it.

Based on current progress, a rough estimate to run all the candidates is about 76 days from now (finishing on June 29th).

Although, hopefully, we will find the one long before the end. With the same estimation, the middlepoint falls on May 22nd. My bet is: end of may (last two weeks) is when we find it.

Just joined up, looks like it could be fun :)
Really quick tasks.
____________
My lucky numbers 1059094^1048576+1 and 224584605939537911+81292139*23#*n for n=0..26

Conclusion 2 - every GPU extra GPU counts. Attaching an additional device will noticeable change finish date.

I just threw an old mac pro on the pile (or perhaps placed, those things are heavy).

The gtx770 in it is finishing 3 wus every 120 seconds, and the 6 cores not servicing the GPU are finishing 6 tasks in 6 minutes. That should work to around 3600/day.

At first I threw almost everything I had at this to see how I would perform, but by now I have either turned off some of my rigs or reallocated them to other projects again (can't stand to have those AMD cards and their beastly DP run anything else than Milkyway for long). Still, with the remaining computers I should be able to work through 10,000+ tasks per day. 14,000, if I keep them running 24/7.
____________
Long live the sievers.

+ Encyclopaedia Metallum: The Metal Archives +

I have to say, this is far more fun than I expected 😁. I found four primes already today!!!
____________
My lucky numbers 1059094^1048576+1 and 224584605939537911+81292139*23#*n for n=0..26

Well, I made simple statistic page to start with. Check it out (also there is a link from main project page). Data is updated every 6 hours.

Well, I made simple statistic page to start with. Check it out (also there is a link from main project page). Data is updated every 6 hours.

Any chance of adding a column for number of digits to the table Stream?
Well done for all your hard work getting this up and running. It's cool.

Any chance of adding a column for number of digits to the table Stream?

Any chance of adding a column for number of digits to the table Stream?

Easy. Visually it look a bit messy now, I'll deal with it later.

The difference between these primes is not so big. First candidate at 22M has 120299 digits, last at 400M - 140937.

Any chance of adding a column for number of digits to the table Stream?

Easy. Visually it look a bit messy now, I'll deal with it later.

The difference between these primes is not so big. First candidate at 22M has 120299 digits, last at 400M - 140937.

That's perfect, thanks Stream 😉

One last thing, it appears to be ordering on
Date (Doublecheck). Probably better to order on initial find date/time, or prime.

One last thing, it appears to be ordering on
Date (Doublecheck). Probably better to order on initial find date/time, or prime.

Actually, the list was in unsorted "natural" ordering, as appeared in result files. But It's obvious that a line was written to result file shortly after candidate has received a double-check result.

Now initial finds will be listed according to their (initial find) timestamps. A disadvantage of this way is that new prime may appear in the middle of your list if it's doublecheck was delayed.

That stats refresh just now got me on the leaderboard, with one prime found and one double checked.

That stats refresh just now got me on the leaderboard, with one prime found and one double checked.

Just completed 20,000 wu's since Friday. :)
____________
My lucky numbers 1059094^1048576+1 and 224584605939537911+81292139*23#*n for n=0..26

Two identical PC's, same boinc version, same nvidia driver, same app_config, same cc_config.

Two identical GPUS in each.

One is downloading just two gpu tasks, the other is maintaining a cache of 9 tasks even though I have set maintain 0 days work.

Any ideas anyone?

Obviously the cache is making it far more likely for wu's to be a DC.

Any pointers would be most appreciated.
____________
My lucky numbers 1059094^1048576+1 and 224584605939537911+81292139*23#*n for n=0..26

Two identical PC's, same boinc version, same nvidia driver, same app_config, same cc_config.

Two identical GPUS in each.

One is downloading just two gpu tasks, the other is maintaining a cache of 9 tasks even though I have set maintain 0 days work.

Any ideas anyone?

Obviously the cache is making it far more likely for wu's to be a DC.

Any pointers would be most appreciated.

Thanks for the detailed explanation Stream. Taken onboard and will experiment. Have to say very well done for setting this all up. I for one and many more no doubt, appreciate it. Big effort for just one person. And great fun. 😎
____________
My lucky numbers 1059094^1048576+1 and 224584605939537911+81292139*23#*n for n=0..26

Next status update will pass 10% mark. Congratulations everybody with this first little step!

Now it's a time for some speculations about "If we'll not find a pair, how long will it take to search whole range?"

Although trivial answer is "10% in 15 days = 150 days total", it's not true. Many powerful crunchers joined the party later. Approximating average rate for last 7 days, the answer will be 90 days.

But... this number is not true again. Very soon, after 7-10 days, CPU tasks will hit maxErr limit and will be disabled. We'll lose part of our computing power. I don't know yet how big these losses will be. Sorry, it requires some complicated queries on database, and I'm afraid of big databases. :) Let's get back to this topic when we'll have some real-life stats.

And conclusion is still the same. Each new attached GPU will noticeable help the project.

Next status update will pass 10% mark.

And conclusion is still the same. Each new attached GPU will noticeable help the project.

56414916 looks like I found it. Happy out! (That translates to - happy as a pig in ....) Hats off to Stream who enabled me to do so, he did all the hard work. 😉. Result! Thanks Dude. Lil bit more virtual graffiti to leave behind. 😁
____________
My lucky numbers 1059094^1048576+1 and 224584605939537911+81292139*23#*n for n=0..26

Update. Now sitting at home, with a large grin on my face, sipping a hot whiskey, feeling good. ;-) dopamine hit achieved, (not from the whiskey) finding this stuff is like a hit from a defibrillator, at times, I would imagine. Early days. Hopefully more to come. Party on Garth!
____________
My lucky numbers 1059094^1048576+1 and 224584605939537911+81292139*23#*n for n=0..26

Oh great. Just write a big message about rates, completion times, and all similar boring stuff. Then wake up in the morning, hit refresh on status page - and whoops... :)

Congratulations to our lucky members!

56414914^16384+1 - discovered by Johnny Rotten, DC by 288larsson
56414916^16384+1 - discovered by Robish, DC by 288larsson

It was fun and exciting. Alas, we need only one such pair. Now it's time for cleanup. The system is currently loaded with candidates up to 65M. They must be purged before normal sequential search could be resumed.

All workunits between 22M and 65M will be considered as part of the search and included in hunt stats. Next, normal search (i.e. all candidates) will be temporary resumed from 65M until cleanup completes. After completion of cleanup, we'll go back to 22M and resume normal search for all untested candidates.

On cleanup phase 1, we must be sure that all workunits below 56414914 are checked and no second pair hides there. This is mandatory because OEIS states that this pair must be minimal possible one. There are only 87 such candidates.

On phase 2, all workunits up to 65M must be processed to finalize stats. There are 54875 candidates (less then one day if we will stay at current rate for a while).

Main part of cleanup should take 7-10 days, mostly because we will wait until abandoned workunits becomes timed out and resent (timeout is 5 days)

Edit: the search took less then 15 days. Started near 2018-04-14 00:00 UTC, and final DC result was returned 2018-04-28 15:23:39 UTC.

A great result! Well done to lucky finders :)
____________
Twitter: IainBethune
Proud member of team "Aggie The Pew". Go Aggie!
3073428256125*2^1290000-1 is Prime!

On the other hand, I have a feeling that something happened too quick :) May be the search could be continued? Although we've reached main goal and solved this mathematical puzzle, we may treat this as a game with rules far more complex and much of luck involved, comparing to classing prime searching. Also, results may have some mathematical purpose. For example: Is there another pair nearby? (in GFN-13, it was). Are these pairs distributed randomly or form close groups? And after all, 90 days required to complete whole range is really not much for professional crunchers :)

The key point is that most powerful crunchers should agree to continue to keep this project fun and short, to stay within predicted 90 days or close to. In last 5 days, we've eliminated 70,000 candidates per day. If we could stay at this rate and even attach more GPUs, everything will be very fast!

What do you think?

I'm up for it. Anyone else?
____________
My lucky numbers 1059094^1048576+1 and 224584605939537911+81292139*23#*n for n=0..26

Congratulations to 288larsson! and well done to everyone.

3, 3, 3, 75, 113, 2163, 63739, 13221, 54809, 3656571, 6992033, 125441, 103859115, 56414915, 87888967, and now a(16)?

Congratulations to 288larsson! and well done to everyone.

3, 3, 3, 75, 113, 2163, 63739, 13221, 54809, 3656571, 6992033, 125441, 103859115, 56414915, 87888967, and now a(16)?

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

Congratulations to the finders and everyone else! Wow, turns out my "end of may" prediction was too pessimistic, haha. =]

I don't have that many resources, but I'm up to search the rest of the genefer limit range for pairs before switching back to methodical "find every prime" search/

Well, I've loaded next set of paired candidates. Let's continue! It will not affect cleanup, the system prioritizes "old" tasks.

I'll be on vacation this week, so stats will temporary continue to work as is. Later I'll split them by "main" part (22M-65M) and "extended" (65-400).

Regarding same search on GFN-13: we already have two pairs for GFN-13. But considering that GFN-13 workunits are 4-5 times faster then GFN-14 and we're already somewhere above 120M on this project, whole range could be searched in 3-4 weeks just for fun.

I will happily update A118539 and A217993 once "phase 1" (ensuring this is the smallest GFN-14 occurrence) is completed? Is it by now?

I'm trying to estimate the size of the adjacent GF primes (the question is "Is a consecutive GFN-16 search reasonable?).

Let I be an interval (the I sides of a dice) and n candidates (n dice rolls).
What is the likelihood that the same value appears consecutively?
Prob = 1 - exp(-n / I).

Now let E(n, b) be the expected number of GF-n primes in [2, b].
The "interval" is I = (b/2) / E(n, b). (b/2 because b is even. Note that it's not true because the distribution is not linear but the estimate is sufficient). The number of candidates is E(n, b) then
Prob(n, b) = 1 - exp(-E(n, b)^2 / (b/2)).

b is computed such that Prob(n, b) = 0.5:

b is computed such that Prob(n, b) = 0.5:

Expected: 4, 4, 33, 59, 805, 4848, 56461, 35843, 199031, 898615, 5856103, 20327026, 97390621, 524510973, 5005442037, 5418679704, 25846060752 Found: 3, 3, 3, 75, 113, 2163, 63739, 13221, 54809, 3656571, 6992033, 125441, 103859115, 56414915, 87888967

Not so bad considering this 'random' distribution.

The most important point is that b_16 ~ b15.
The reason is the prime 65537: because of it the number of GF-16 primes in [2, b] is about the same than the number of GF-15 primes.

A consecutive GFN-16 search can succeed. The limit of Genefer (400M) can be extended (the theoretical bound is sqrt((127*2^24+1)*(15*2^27+1)*(51*2^25+1) / 2 / 65536) ~ 236000M).

The search for all pairs in 2-400M for GFN-13 and GFN-14 is useful for estimating the gap between pairs (which is a better estimate than the first pair).

I have some data on the GFN-16 search since we moved it from PRPNet to BOINC:

In the two and a half years GFN-16 has been running on BOINC, we've tested about 5.4 million candidates. For about 1.5 million of those candidates (b^65536+1), b+2 was also in the sieve file and was tested. These are the candidates that would be of interest in a search for a GFN-16 pair.

Of those 1.5 million candidates, 100 (exactly) have been prime. For all of those 100 primes, (b+2)^65536+1 is composite.

We can learn a few things from this information:

* A fairly large percentage of all candidates are potential pairs. (1555973 out of 5504246, or 28%)

* Only a small percentage of candidates are prime (346 out of 5470263, or 0.006%)

* Put another way, one out of every 15810 candidates is prime.

* In 2.5 years we've found 100 primes where there was another candidate that would have been a pair if it had been prime. If we had restricted the search to only candidates that could potentially be a pair, we probably would have found about 4 times as many (400).

* 15810/400 is 39.5 Call it 40. 40 times 2.5 years is 100 years. Based on past performance, that's how long it should take to find a GFN-16 pair. Of course hardware will improve a lot in the next 100 years, so it won't really take that long.

It's clear that barring exceptional luck, even if we're specifically searching for a pair, the search for a GFN-16 pair will likely take a lot longer than it took to find a pair for 15, 14, or 13.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

For about 1.5 million of those candidates (b^65536+1), b+2 was also in the sieve file and was tested. These are the candidates that would be of interest in a search for a GFN-16 pair.
...
* A fairly large percentage of all candidates are potential pairs. (1555973 out of 5504246, or 28%)

For about 1.5 million of those candidates (b^65536+1), b+2 was also in the sieve file and was tested. These are the candidates that would be of interest in a search for a GFN-16 pair.
...
* A fairly large percentage of all candidates are potential pairs. (1555973 out of 5504246, or 28%)

If you calculated number of possible candidates exactly as described, it's not correct. You should check every second candidate in sequence. In your terms, b-2 must also be in the sieve file and, if it's true, b+2 must be skipped. If you have a sequence of three candidates, only middle one must be tested, because proving it composite will cancel both pairs.

In GFN-14 we had 5,6 times less candidates to test comparing to original sieve file, i.e. 17,9%. I think your numbers must be closer to this value.

Assuming I'm following your analysis correctly, it seems to me that finding a GFN-15 pair was a very lucky occurrence. Failing the same sort of luck on GFN-16, wouldn't an awful lot of searching be required?

Is there a reason to expect that we would be as lucky when looking for the GFN-16 pair?

Otherwise a(16) may be "out of range".

First phase of cleanup completed today, and I could confirm that 56414914 and 56414916 are lowest possible GFN-14 pair, and it could be reported to OEIS now.

Credit

Credit is assigned according to PrimeGrid rules. But this is not a PrimeGrid server, so credit stays here. Only if we could convince Michael to transfer credit back to PG accounts :))) (to the GFN or PSA, during hunt period only). But even if we do, it will be manual procedure which will happen rarely (for example, each 10 days), similar to PSA. So why it's necessary to have same email address here and on PG - for automatic account matching.

Credit

Credit is assigned according to PrimeGrid rules. But this is not a PrimeGrid server, so credit stays here. Only if we could convince Michael to transfer credit back to PG accounts :))) (to the GFN or PSA, during hunt period only). But even if we do, it will be manual procedure which will happen rarely (for example, each 10 days), similar to PSA. So why it's necessary to have same email address here and on PG - for automatic account matching.

Michael, any plans to port credit/primes over to PrimeGrid?

Even as a once off exercise at the end of the hunt?

Michael, any plans to port credit/primes over to PrimeGrid?

Even as a once off exercise at the end of the hunt?

I like what you've done to the hunt status page stream. Splitting the stats into ranges. Nice.

Would there be a way to add a column for total tasks done per user? Might be interesting to see the numbers go up.
Might also highlight if a machine has gone offline.

If it's too difficult no worries.

Cheers Rob

____________
My lucky numbers 1059094^1048576+1 and 224584605939537911+81292139*23#*n for n=0..26

Would there be a way to add a column for total tasks done per user? Might be interesting to see the numbers go up.

Would there be a way to add a column for total tasks done per user? Might be interesting to see the numbers go up.

It's not difficult at all. I've added total tasks and credit columns, but with two limitations:

- The whole logic of the script is based on discovered primes so peoples without primes will be not listed;
- This script reads assimilator log files, i.e. it counts "Completed and validated" tasks. Tasks in "Validation pending" state are not included.

Great stuff. Is that the total so far, or within the range?

Great stuff. Is that the total so far, or within the range?

Hmm... which 'total' exactly ?

"Time" and "Candidates tested" are since beginning of project. (i.e. 'base' search did 11,39% of search space, and now we're at 15.85%).

Number of primes, tasks and credit are within the range.

Stream,

I just noticed GFN13 is running too.
I might let some slower boxes run them.
But is there somewhere to check if I got any primes?
I cant see a link anywhere.

Cheers

Rob.
____________
My lucky numbers 1059094^1048576+1 and 224584605939537911+81292139*23#*n for n=0..26

I just noticed GFN13 is running too.
I might let some slower boxes run them.

But is there somewhere to check if I got any primes?
I cant see a link anywhere.

I just noticed GFN13 is running too.
I might let some slower boxes run them.

First warning (which may make rest of the answer useless) - GFN-13 is GPU-only. We are above Genefer maxErr limit. If your "slower boxes" means slower CPUs, this will not work. GFN-14 is very close to CPU maxErr limit too, I expect we reach it in no more then 3 weeks; with our speed, I may have to disable CPU tasks suddenly. Use these boxes on GFN-14, while it's still possible.

But is there somewhere to check if I got any primes?
I cant see a link anywhere.

Note that GFN13 is currently running standard sequential search. Of course it may be changed to "pair hunt" mode too, but it's not strictly necessary - we already know two GFN-13 pairs, and amount of tasks is so small that remaining part of search space could be searched for pairs in 2-3 weeks. I'm thinking to keep this work as a "backup" - when we reach end of GFN-14 (in pair mode) and will do a cleanup of abandoned/lost tasks, no new GFN-14 work will be available during this period.

You are correct, this information is not accessible online yet. Although I started to implement some statistical bells and whistles on the server, this wish could not be done in 10 minutes like previous one. Right now we have 7726 primes reported to to http://primegrid.com/gfn_history13.php, and significant amount is pending to report. Same applies to "classic" part of GFN-14 (up to 22M). I must think first about UI and some coding details. Consider this in my todo list, but don't expect immediate implementation.