Current project status

Project goal has been reached! 09 March 2020 first GFN-16 MEGA prime was found by Robish. See this post for details.

Сleanup of remaining workunits finished 05 May 2020. Project closed.

Total candidates tested: up to b_min+310000


Timeline:
2019-03-14: Project started
2020-03-09: Two GFN-16 MEGA primes discovered
2020-04-15: Started project cleanup before shutdown
2020-05-05: Cleanup finished, project closed.

Project description

We would like to invite you to small and fun side project, the search for first GFN-16 Mega Prime!

As JeppeSN noticed, first mega prime (>= 1'000'000 digits) is known for GFN-17 and above, but not for GFN-16 and below. GFN-15 and below requires very high b to reach 1M digits, above all software limits. For GFN-16, this goal is possible.

How it works

We will search for a prime starting from b_min=1814570322693370 (i.e. 1814570322693370⁶⁵⁵³⁶+1, lowest candidate with 1'000'000 digits) up to b_min+1000000. This b is above Genefer limit, so we'll use standard LLR software, which all of you should be familiar with from PrimeGrid projects. There are about 156'000 candidates to test.

The prime is a true mega prime and will be reported to T5K.

It may be smallest mega prime ever found.

Schedule

The search will be started at March, 14, 2019, 12:00 UTC (plus-minus few minutes, daemons on this server are slow and lazy beasts, they need a minute or two to scan database and fill buffers with tasks).

This search is planned to be stopped when prime is found and cleanup completes (to be sure that no primes below are missed), but this decision is not final. It's expected to have 3-4 primes in the search range, and they could be anywhere. We may find a prime on the second day of the search, lacking all fun. In this case, search could be expanded until next prime is found or even for full test range.

How to participate

The search is held on my experimental GFN server. To participate as new user, please register at this 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.

- 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"

After registration, please change your computing preferences. By default server will send you GFN-13 (if you have GPU) and a mix of GFN-14 and GFN-16 MEGA tasks. Go to "Your account" -> "Computing Preferences" and select GFN-16 only or GFN-16 + GFN-13 if you want to participate in second experimental GPU-only 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.

Optimizing performance

Tasks will took 4-8 hours on modern processors with FMA3 (for a single core). LLR multithreading will help to use CPU cache better and improve overall throughput.

LLR multithreading was discussed may times on PG forums and I'll not repeat here everything. Application name for app_config.xml is gfn16_mega, and minimal app_config.xml for 4 threads may look like this:

Small typo in the app_config, the / is missing from the closing app_config.

I'm in :)
____________
My lucky numbers 1059094^1048576+1 and 224584605939537911+81292139*23#*n for n=0..26

Do you have a plan for submitting to T5K?
Or would the lucky finder have to do it themselves?
Not that it's hard, but getting the Proof code right for person, project and software is important, and we wouldn't want someone else submitting it!
Forewarned is forearmed :-)
____________

Do you have a plan for submitting to T5K?
Or would the lucky finder have to do it themselves?
Not that it's hard, but getting the Proof code right for person, project and software is important, and we wouldn't want someone else submitting it!
Forewarned is forearmed :-)

I am getting only this:

Th 14 Mar 2019 07:27:14 CET | PRIVATE GFN SERVER | No tasks are available for GFN-16 MEGA Prime Search

____________
DeleteNull

I am getting only this:

Th 14 Mar 2019 07:27:14 CET | PRIVATE GFN SERVER | No tasks are available for GFN-16 MEGA Prime Search

Do you have a plan for submitting to T5K?
Or would the lucky finder have to do it themselves?
Not that it's hard, but getting the Proof code right for person, project and software is important, and we wouldn't want someone else submitting it!
Forewarned is forearmed :-)

Exact answer on this question will depend on who'll find this prime. Many primes finders here (including myself) already have accounts created and managed by PG.

Wow, first result already returned at 13:52 UTC, it was less then two hours! Two more were returned few minutes later. Alas, they weren't primes... :)

To report a prime to T5K, you need (1) a user account and (2) a proof coce
____________
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!

Hello Doctor,

I am using (8x8 threads, cc_config with 8 ncpus):
<app_config>
<app>
<name>gfn16_mega</name>
<fraction_done_exact/>
<max_concurrent>8</max_concurrent>
</app>
<app_version>
<app_name>gfn16_mega</app_name>
<cmdline>-t 8</cmdline>
<avg_ncpus>1</avg_ncpus>
<max_ncpus>1</max_ncpus>
</app_version>
</app_config>

This works fine for me.
____________
DeleteNull

I've only had the smallest amount of contact with configuring multithreaded apps, but is there a limit on how scalable this one is? I can't get it to use more than about 65% of the CPU power despite setting it to use 9 of the 10 cores available.

<app_config> <app_version> <app_name>gfn16_mega</app_name> <cmdline>-t 4</cmdline> <avg_ncpus>4</avg_ncpus> </app_version> </app_config>

Well, even if there was a typo there which I fixed before even trying first, this "minimal" xml doesn't work (for me) - I get a syntax error nevertheless and lost my wus several times now.
As far as I could see in the project folder the app name is NOT gfn16_mega but cllr64.3.8.21.exe, so I tried it with a more detailed one like this:
<app_config>
<app_version>
<app_name>gfn16_mega</app_name>
<user_friendly_name>GFN-16 MEGA Prime Search</user_friendly_name>
<version_num>801</version_num>
<file_ref>
<file_name>cllr64.3.8.21.exe</file_name>
<main_program/>
</file_ref>
<cmdline>-t 6</cmdline>
<avg_ncpus>6</avg_ncpus>
</app_version>
</app_config>
But it still doesn't work - I don't get where the mistake is...

I've only had the smallest amount of contact with configuring multithreaded apps, but is there a limit on how scalable this one is? I can't get it to use more than about 65% of the CPU power despite setting it to use 9 of the 10 cores available.

Stream. Any metrics on 16mega wus? Number sent out, returned etc? Just to guage the interest. Cheers Rob
____________
My lucky numbers 1059094^1048576+1 and 224584605939537911+81292139*23#*n for n=0..26

Stream. Any metrics on 16mega wus? Number sent out, returned etc? Just to guage the interest. Cheers Rob

Stream. Any metrics on 16mega wus? Number sent out, returned etc? Just to guage the interest. Cheers Rob

After 24 hours:

Returned with success: 223
Returned with error: 0 (not including manually aborted tasks)
In progress: 494
I'll not post number of sent tasks, it's just a sum of all above.
Highest candidate returned (leading edge): b_min+6770

Validation is not enabled yet, everybody will receive only primary-checker tasks for some time.

Will finders be rewarded with an "M" badge?

Hi Stream

Любое обновление о Первом поиске MEGA - скоро :)

Мы нашли что-нибудь еще?

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

Rob, you intended to ask "did we find anything yet?", but your question reads as "is there anything else we found?". I appreciate the attempt, though! I'm always in favor of people learning languages.

Rob, you intended to ask "did we find anything yet?", but your question reads as "is there anything else we found?". I appreciate the attempt, though! I'm always in favor of people learning languages.

Любое обновление о Первом поиске MEGA - скоро :)

Любое обновление о Первом поиске MEGA - скоро :)

:)))

OK, here is an update.

After 4 days:
------------------------------------------
Returned with success: 1018
Returned with error: 25 (not including manually aborted tasks)
In progress: 588
Leading edge: b_min+10482
No primes yet.
------------------------------------------

Leading edge is an estimated value. This version of server software is sending tasks in random order, selecting them from intermediate buffer of 450 tasks. It can be any number of tasks below leading edge which even wasn't sent to first host. The buffer itself is filled from database sequentially, ordered by 'b'

After 10 days:

Completed successfully: 2932
Completed with error: 29
In progress: 376
Estimated leading edge: b_min+23136

After 10 days:

Completed successfully: 2932
Completed with error: 29
In progress: 376
Estimated leading edge: b_min+23136

At the current participation rate it's looking like about a 2 or 3 year project.

That is until we find a prime, which would probably see more people coming on board.

At the current participation rate it's looking like about a 2 or 3 year project.

That is until we find a prime, which would probably see more people coming on board.

No, it's too pessimistic. The goal of project is to find first mega prime for GFN-16. There is no need to test whole range, other primes will not have scientific meaning. We can try to find 1-2 other primes just for fun if we find first prime too fast (2-3 months).

How long could it take to find first prime? First of all, it's a lottery, we may find it tomorrow. Talking about averages and probabilities, JeppeSN mentioned that prediction is 3.89 primes in the interval of length 800'000, which give us that we should test (in average) interval of ~206K per prime. Let's take even more pessimistic value of 300K. Then, using our rate after 10 days, we have following rough estimation:

leading edge 23136 - 10 days
leading edge 300'000 - 130 days
Total: it should take no more then 260 days (130*2 due to double-checking)

I have done 20 WUs so far, all but three are solo, no wingman, and the three timed out before I even joined.

After 10 days:

Completed successfully: 2932
Completed with error: 29
In progress: 376
Estimated leading edge: b_min+23136

After 20 days Stream?

After 20 days Stream?

Completed successfully: 5285
In progress: 247
Estimated leading edge: b_min+38302
No primes yet.

As usual, estimated leading edge is indeed estimated. It's better to use number of successfully completed tasks to describe project progress.

Validation is not enabled yet, everybody will receive only primary-checker tasks for some time.

What are the plans for turning on double-checking? It can be helpful for the owners of the individual hosts to detect if some computer is not crunching properly. /JeppeSN

After 1 month:

Completed successfully: 7640
In progress: 205
Estimated leading edge: b_min+51918
No primes yet.

There are total of 150'000 candidates and 4 possible primes in the whole 1M range, so we may expect to find one prime per 37500 candidates (average), or within b_min+250000. Thus, we made quite good progress in this month, completing (in one pass) more then 20% of these numbers.

I've made a simple scoreboard for this project: http://boincvm.proxyma.ru:30080/test4vm/user_profile/gfn16_hunt_status.html

Optimizing performance

Tasks will took 4-8 hours on modern processors with FMA3 (for a single core). LLR multithreading will help to use CPU cache better and improve overall throughput.

Just a quick question for understanding this since I'm currently a bit wondering about my runtimes in comparison to others sometimes:
Is this app ONLY using FMA3 or does it also use others like AVX etc.?

Wow - Robish is hammering it!
____________

anyone else seeing hanging tasks on this project? my machine seems to be unable to report or get new tasks. I know the 'job cache full' is because the machine grabbed tasks from PG, but currently have four tasks waiting to report results on the machine.

stream: still seeing the same issue from my side, wondering if it's just me or everyone.

When your clients sends a POST request to scheduler, my Apache reports an error

(70007)The timeout specified has expired: [client *****] AH01224: Timeout during reading request entity data

I.e. it cannot receive complete POST request from you.

cc_config.xml

<max_tasks_reported>N</max_tasks_reported> Report at most N tasks per scheduler RPC. Try N=1000 if your computer has lots of tasks to report and is having trouble completing a scheduler RPC.

I did a little bit of packet capture (and understand, I'm no network engineer) and I see my machine talking to the private server, but when it gets to the 'scheduler request' packets, I don't see any response, so it retries several times with no response.

@TimT Have you tried to flush the DNS and reconnect? On windows, enter the following on the command line:

ipconfig /flushdns


I don't remember the command in Linux if that is the OS on the machine having trouble.

@TimT Have you tried to flush the DNS and reconnect? On windows, enter the following on the command line:

ipconfig /flushdns

I don't remember the command in Linux if that is the OS on the machine having trouble.

The POST requests are generally often split by various libraries into 2+ separate TCP packets – the header and the body (the body is often multiple packets itself when the request is big). I've found that out myself at work about few months ago when the task I was doing required maximizing throughput of a high amount of parallel stream messaging (done with POSTs). The messages were very short, just like 20 bytes of data posted, the headers were much bigger themselves.

This is also highly connected to implementations of the Nagle's algorithm (see wikipedia if needed). If I recall correctly, in my case throughput was much better when disabling nagle algorithm – while it was on (by default in dotnet framework implementation of httpclient) each POST was two packets as described, with it off it was a single packet.

This of course is very unlikely to help the problem since nagling is about throughput, not the ability to send packets at all. But it's an insight about how there's probably this separation of packets into headers and bodies.

P.S. Yeah, and the reason why throughput in my case was higher with single packets was because the client would wait for the web server to answer to the first packet while the webserver waits some tiny amount of time expecting the continuation before sending the ACK to the first (this is also related to Expect100Continue stuff) – that tiny amount is negligible when you're sending a single request, but not when trying to optimize throughput.

Got a packet capture, seems to be low-level TCP/IP problem (not related to applications). First packet of request body never reaches input interface on my router. May be it's MTU/MSS problem somewhere in the middle (this packet should be of maximum length), may be problem is in these damn ISPs which have lot of traffic ananyzers and ALG's these days which may trigger on some data inside packet where they should not.

TL;DR: try to set

MSS=1460 seems to be wrong. I'm on L2TP so it must be 1420. I found that my router is working in Path MTU Discovery (PMTUD) mode. According to Cisco doc, "a disadvantage of this mode is that it does not work reliable on the Internet" :) Also see https://en.wikipedia.org/wiki/Black_hole_(networking)#PMTUD_black_holes Which seems to be your case - some router on your side, or between me and you fails to support PMTUD, probably blocks ICMP. (on your side because it works for everybody else).

I'll think what can be done here.

You may be able to reduce MSS on your server socket to something sufficiently low.
However, it may still be a no-op, since many other connections are working fine.
____________

edit: (and just for kicks, here's what my traceroute looks like -- I'm guessing ICMP has a snowball's chance of making it here)

13 pe01.Tula.gldn.net (79.104.234.111) 137.345 ms pe01.Tula.gldn.net (79.104.234.109) 148.946 ms pe02.Tula.gldn.net (79.104.234.103) 159.807 ms 14 194.154.95.7 (194.154.95.7) 140.276 ms 79.104.58.126 (79.104.58.126) 130.927 ms 134.810 ms 15 * * * 16 * * *

ip route add 128.73.162.179/32 via 10.10.0.1 dev eno2 advmss 1400 mtu 1400

Roughly 1/3rd of the way there! :)

Edit: but it could be tomorrow ;)
____________
My lucky numbers 1059094^1048576+1 and 224584605939537911+81292139*23#*n for n=0..26

Roughly 1/3rd of the way there! :)

Edit: but it could be tomorrow ;)

Why, to me it looks like we are much less than one third of the way?

http://boincvm.proxyma.ru:30080/test4vm/user_profile/gfn16_hunt_status.html estimates leading edge as bmin+86248, and if we want to go to bmin+1000000 i necessary (which it should not be!), then we have done only 8.6%. And if we consider double-checking also, we are not even that far.

Roughly 1/3rd of the way there! :)

Edit: but it could be tomorrow ;)

Why, to me it looks like we are much less than one third of the way?

http://boincvm.proxyma.ru:30080/test4vm/user_profile/gfn16_hunt_status.html estimates leading edge as bmin+86248, and if we want to go to bmin+1000000 i necessary (which it should not be!), then we have done only 8.6%. And if we consider double-checking also, we are not even that far.

/JeppeSN

After 2 months, we did 14473 tasks reaching estimated leading edge of 97624. The progress is a bit less then in first month but very close, so I could say that we're working at stable rate. Scaling to average distance between primes (250'000), our current progress is 39% by leading edge or at 19,5% overall (considering doublechecking).

As I've mentioned early, full automatic double-checking will be turned on when leading edge reaches 100'000. It should happens in 2-3 days - only 800 tasks left.

After 2 months, we did 14473 tasks reaching estimated leading edge of 97624. The progress is a bit less then in first month but very close, so I could say that we're working at stable rate. Scaling to average distance between primes (250'000), our current progress is 39% by leading edge or at 19,5% overall (considering doublechecking).

As I've mentioned early, full automatic double-checking will be turned on when leading edge reaches 100'000. It should happens in 2-3 days - only 800 tasks left.

If we were to do the entire range, with double checking, we would not finish before 2021. /JeppeSN

After 2 months, we did 14473 tasks reaching estimated leading edge of 97624. The progress is a bit less then in first month but very close, so I could say that we're working at stable rate. Scaling to average distance between primes (250'000), our current progress is 39% by leading edge or at 19,5% overall (considering doublechecking).

As I've mentioned early, full automatic double-checking will be turned on when leading edge reaches 100'000. It should happens in 2-3 days - only 800 tasks left.

If we were to do the entire range, with double checking, we would not finish before 2021. /JeppeSN

Main goal of the project is to find only one - first mega-prime (out of 4 predicted), and I hope it will happen faster. But it's a lottery.

Is the server down? I'm getting connection timeouts since about 15:01 EEST (12:01 UTC) and some online tools show it down too.

Is the server down? I'm getting connection timeouts since about 15:01 EEST (12:01 UTC) and some online tools show it down too.

Is the server down? I'm getting connection timeouts since about 15:01 EEST (12:01 UTC) and some online tools show it down too.

I've been working on the server for the past six hours without any problems. No timeouts and my ssh sessions have been fine.

Is the server down? I'm getting connection timeouts since about 15:01 EEST (12:01 UTC) and some online tools show it down too.

I've been working on the server for the past six hours without any problems. No timeouts and my ssh sessions have been fine.

I was talking about the Private GFN Server.

It's not clear what happened there. The outer perimeter is working but some office servers, including GFN server, are unreachable. Since it's a Sunday evening here, please wait for few hours, when I'll be back in the office in the Monday morning.

It's not clear what happened there. The outer perimeter is working but some office servers, including GFN server, are unreachable. Since it's a Sunday evening here, please wait for few hours, when I'll be back in the office in the Monday morning.