UPDATE: The project is now live!


We'll be searching for Fermat Divisors in two stages:
First, we'll search k=19683 up to n=4M (probably; there's still some talk about where exactly it stops). This will get done really quickly.

Second phase is searching 5<=k<=49 up to 9M. This part will take longer.

With a little luck, we hope to have this running later today.

If you are using app_config or app_info, that app name is llrDIV.

The project abbreviation is PPS-DIV.

This is considered part of PPS, so it uses the PPS-LLR stats and badge.

This project will end (permanently) when we get to n-9M.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

In project settings, I cannot check the box to select it. The box is there, but is not selectable.

Edit: Duh. Helps if I read what you wrote...

With a little luck, we hope to have this running later today.

All known Fermat divisors are listed here. We expect this search to find about two new Fermat divisors; it has about an 85% chance of finding at least one. With the exception of the small k=19683 candidates, any new Fermat divisor found in this subproject would overtake 193*2^3329782+1 as the largest one known.

The project is LIVE!!!

You can all now select this in Project Preferences.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

Is this one of the LLR projects that does better MT, or better as single-threaded?
____________
Reno, NV

Is this one of the LLR projects that does better MT, or better as single-threaded?

The preferences page is recommending MT.

Multi-threading is supported but is NOT recommended. Click here to set the maximum number of threads.

Is this one of the LLR projects that does better MT, or better as single-threaded?

The preferences page is recommending MT.

hmm. That's not what I am seeing:

Multi-threading is supported but is NOT recommended. Click here to set the maximum number of threads.

Is this one of the LLR projects that does better MT, or better as single-threaded?

Does only the first finder get the red F? If so I'm afraid the server will get overloaded really quickly.

There are *so* many jokes I want to make, but can't because of the rules.

plan class mt?

Does only the first finder get the red F? If so I'm afraid the server will get overloaded really quickly.

There are *so* many jokes I want to make, but can't because of the rules.

I get why you're doing low k's - they get more gfns. But what's so special about k=19683?

It took just 6.5 minutes to complete a task on my i5-5250U. This is exciting!
____________
8915 × 2 ^ 1507177 + 1 -- 453,710 digit PPSE
6603 × 2 ^ 1411654 + 1 -- 424,955 digit PPSE (DC)

Since this is a special project can the F badge have a little gold star in the corner to distinguish it from a "regular" F badge? :)

Second phase is searching 5<=k<=49 up to 9M. This part will take longer.

This is progressing very quickly. I'm already getting new tasks with n = 1.3 M. Does that mean we're roughly one-third through the first phase?

At the start FFT size was 30k (smallest that I saw), now up to 120k. Probably still optimal throughput for most to run at least 1 task per core.

I get why you're doing low k's - they get more gfns. But what's so special about k=19683?

19683 = 3^9. A technical analysis by Ravi Fernando suggest that for this special k, the chance of a prime being a Fermat divisor should be 1/3^6 = 1/729 for even n and 1/3^7 = 1/2187 for odd n. I think that means it is rational to search 19683 to approximately the same depth as we have searched k near k=729 or k=2187.

I do not think anyone had searched k=19683 before Ravi F. did his analysis.

/JeppeSN

Second phase is searching 5<=k<=49 up to 9M. This part will take longer.

Does that include k=27? If so, are we doublechecking the results of the ongoing PRPNet effort or just skipping to n>7.5M for that k?

When we come to the small k, here is the "table" we try to extend:

3: 41, 209, 157169, 213321, 303093, 382449, 2145353, 2478785
5: 7, 25, 39, 75, 127, 1947, 3313, 23473, 125413
7: 14, 120, 290, 320, 95330, 2167800
9: 67, 9431, 461081, 2543551
11: 18759, 960901
13: 20, 114296
15: 229
17: 147, 747, 6539
19: 6838, 9450, 23290
21: 41, 276, 94801
23:
25: 2141884
27: 455, 672007
29: 57, 231, 2027, 4727
31:
33: 18766
35:
37: 16
39: 13, 113549
41:
43:
45:
47:
49:

Each row is of the form:

k: (all known n that make k*2^n+1 a Fermat divisors)

/JeppeSN

This is quite the exciting opportunity. I’ll keep a computer on this for a good little bit.
____________

Might be time to start thinking about running 2 threads per task, for some CPUs.

Biggest FFT size I see is 192k, which for one task per core, is about the limit for 1.5MB/core L3 cache CPUs (mostly i5, some i3). I don't have any active so can't check myself right now.

CPUs I'm running currently are 2MB/core or more, so they see a bit of a drop in efficiency going to 2 thread. Fastest system with 7920X in it was around 1000s per unit one per core, dropping to 600s per task after switching to 2 threads each.


Also, this is the first time I played with the new thread settings. Easier than editing files on each system!

For people who are wondering "why 19683?": great question! I started a new thread here.

Seems like Tasks are now taking longer and longer to complete then when we first started.
Went from 3 Minutes to now over 12 minutes to complete.

This list states that certain n-ranges for k=11, 13, 15, and 47 have been searched completely; we can infer that Serge also searched up to the prime he found for k=9. But those ranges were tested outside of PrimeGrid, presumably with no double-checking, so we won't trust them. (The numbers on the stats pages you link were tested on PrimeGrid several years ago, when PPS was run differently.)

For those five ranges, my calculations would predict about 3.8 primes and 0.27 Fermat divisors. For the remainder of the low-k range, my calculations predict about 45 primes (depending somewhat on whether you include the non-divisor candidates with k=9 and 27), and 1.93 divisors. So we're not missing out on all that much.

With real data and real candidates to work wirth, I've got a better estimate of how long this project will run.

The new estimate is 24 months.

Also, we've added 5 additional k's, which will stop at n=3.322M. The 5 new k's are 1323 (even n only), 2187 (even n only), 3125, 3267 (even n only) and 3375.

The new k's start at a lower n than where we are now, so you'll see the task size decrease for a little while once the new k's make their way through the queue. That should happen in an hour or three.


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

24 months is longer than I was expecting. I was looking forward to blitzing through a short project. I’ll still keep chugging through as many of these WUs as I can, but will probably go back to switching around between badges after a few weeks.
____________

Are you taking into account that some of our search area may have been exhausted by prime hunters outside PrimeGrid?

I see the following primes:

9*2^5642513+1
11*2^3771821+1
13*2^4998362+1
15*2^4246384+1

I guess some of these k values can be "sieved" by removing values that cannot lead to primes because of algebraic factorizations.

As an example, for k=2187, every time n is divisible by 7, we have

2187 * 2^{j*7} + 1 = (3 * 2^j)^7 + 1,

and that can never be prime because certainly

x^7 + 1 = (x + 1)*(x^6 - x^5 + x^4 - x^3 + x^2 - x + 1).

Here's a table showing our progress, by k:

How often will you update that table? 1 % or some other increment?

I plan on running this even though I've had a F badge since 2008.

On 27 Dec 2008 23:01:43 UTC, PrimeGrid's first Fermat divisor in the Proth Prime Search
project was discovered:
651*2476632+1 Divides F(476624)

Ooh, more fancy tables.

How often will you update that table? 1 % or some other increment?

How about putting it at Subproject status page?
https://www.primegrid.com/stats_div_llr.php

Depending on how expensive this SQL is, it can be updated once an hour, once a day or when clicked.

I plan on running this even though I've had a F badge since 2008.

On 27 Dec 2008 23:01:43 UTC, PrimeGrid's first Fermat divisor in the Proth Prime Search
project was discovered:
651*2476632+1 Divides F(476624)

Looking at the different k's we're running, it's quite the convoluted timeline. Chronologically, from the project start:

Past:
* k=19683 starts at n=300,000. (0.17%)
* k's 1323, 2187, 3125, 3267, and 3375 are added at n=1,550,000. K=19683 waits at n=2,465,176 for the 5 new k's to catch up. (0.38%)

Future:
* At n=2,465,176, k=19863 will start going out again. (0.84%)
* At n=3,221,996 the 5 k's 1323, 2187, 3125, 3267, and 3375 will be completed, and only k=19863 will continue. (0.28%)
* At n=3,640,000 the 20 odd k's from 11 to 49 are added. (2.23%)
* At n=4,000,000 k=19683 is completed and k=9 is added. (20.72%)
* At n=6,000,000 k's 5 and 7 are added. (75.38%)
* At n=9,000,000 the 23 odd k's from 5 to 49 are completed and the project is over.

The percentages are the amount of work for that stage of the project. Although the percentages are (mostly) increasing at each step, these numbers are for the individual project phase, not the cumulative amount.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

Greetings, my ... findings have changed ... i have 903 finds in pps ... instead of 902 ... i'm counting ... on all the 8 servers and one laptop dell rugged extreme 7404 only ' the new subroject ' ,
on GPU, collatz, milkyway, gnf extreme, and gpugrid ... will there be an information, of a new Fermat find? ... when i look into pps finds, there is no detailed information.

sincerely, Grzegorz Roman Granowski ... The Scottish Boinc Team ...

Grzegorz Roman Granowski wrote:

Greetings, my ... findings have changed ... i have 903 finds in pps ... instead of 902 ... i'm counting ... on all the 8 servers and one laptop dell rugged extreme 7404 only ' the new subroject ' ,
on GPU, collatz, milkyway, gnf extreme, and gpugrid ... will there be an information, of a new Fermat find? ... when i look into pps finds, there is no detailed information.

sincerely, Grzegorz Roman Granowski ... The Scottish Boinc Team ...

You were the double checker on one of the PPS-DIV primes found so far. It's not a divisor, however.

https://www.primegrid.com/workunit.php?wuid=622990206

thank You, will there be a detailed information, in my pps ... statistics ... nevertheless ... i've noticed ... a change from 902 to 903 finds, I was not able to find it .... sincerely, Grzegorz Roman Granowski ...

But there are also "base 3" Pierpont primes known....

/JeppeSN

With Honza's new prime 2187*2^2786802+1, we've now found at least one prime for each of the six large k's we're searching. That one is also a Pierpont prime, since 2187 = 3^7.

But there are also "base 3" Pierpont primes known....
/JeppeSN

What will be other K in base 3?

At what point would it be best to switch to multithreading? Once they surpass the size of PPS-MEGA maybe?

At what point would it be best to switch to multithreading? Once they surpass the size of PPS-MEGA maybe?

At what point would it be best to switch to multithreading? Once they surpass the size of PPS-MEGA maybe?

At what point would it be best to switch to multithreading? Once they surpass the size of PPS-MEGA maybe?

Well, you can look at the FFT size of your Results, multiply by 8, multiply by number of cores used, and see if that exceeds your CPU's cache.

If it does, multithreading is probably a good idea. If it doesn't, but your machine is slow and not getting (1st) often, you can multithread anyway.

Another way of looking at progress:

<app>
<name>llrDIV</name>
<fraction_done_exact/>
</app>
<app_version>
<app_name>llrDIV</app_name>
<plan_class>mt</plan_class>
<cmdline>-t 3</cmdline>
<avg_ncpus>3</avg_ncpus>
<max_ncpus>3</max_ncpus>
<max_concurrent>1</max_concurrent>
</app_version>

what am I doing wrong ?

PrimeGrid: Notice from BOINC
Your app_config.xml file refers to an unknown application 'llrDIV'. Known applications: 'llrMEGA', 'genefer17mega', 'ap26', 'llrSR5', 'llrTPS', 'genefer15', 'llrCUL', 'llrPPS', 'llrSOB', 'llrTRP', 'llrPPSE', 'llrESP', 'llrWOO', 'llr321', 'llrPSP', 'gcw_sieve', 'trp_sr2sieve', 'genefer16', 'genefer17low', 'genefer18', 'genefer19', 'genefer20', 'genefer', 'genefer_wr', 'pps_sr2sieve'

We're now 1% done: