• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

PrimeGrid Challenge Series 2026

Page 3 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.
number 8, right before I go under the knife..... surgery tomorrow.

Dear Primefinder,

Congratulations! Our records indicate that a computer registered by you has found a unique prime number. This computer is running BOINC, is attached to the PrimeGrid project, and is assigned to the Generalized Fermat Prime Search n=17 Mega (GFN-17-Mega). What makes this prime unique is that it's large enough to enter the Top 5000 List in The Largest Known Primes Database.

Since you have auto-reporting selected, the following prime was submitted on your behalf:

Added 141943 : 461268310^131072+1 (1135602 digits)

This prime was found on this workunit which will automatically show as a prime result after verification by the Largest Known Primes Database.

If you have any questions or concerns, please contact us and we will surely resolve any problems.

Once again, congratulations on your find! Thank you for participating in PrimeGrid.

PrimeGrid staff
 
Yes from the hospital, stillhere

Dear Primefinder,

Congratulations! Our records indicate that a computer registered by you has found a unique prime number. This computer is running BOINC, is attached to the PrimeGrid project, and is assigned to the Generalized Fermat Prime Search n=17 Mega (GFN-17-Mega). What makes this prime unique is that it's large enough to enter the Top 5000 List in The Largest Known Primes Database.

Since you have auto-reporting selected, the following prime was submitted on your behalf:

Added 142003 : 467885520^131072+1 (1136413 digits)

This prime was found on this workunit which will automatically show as a prime result after verification by the Largest Known Primes Database.

If you have any questions or concerns, please contact us and we will surely resolve any problems.

Once again, congratulations on your find! Thank you for participating in PrimeGrid.

PrimeGrid staff
Dear Primefinder,

Congratulations! Our records indicate that a computer registered by you has found a unique prime number. This computer is running BOINC, is attached to the PrimeGrid project, and is assigned to the Generalized Fermat Prime Search n=17 Mega (GFN-17-Mega). What makes this prime unique is that it's large enough to enter the Top 5000 List in The Largest Known Primes Database.

Since you have auto-reporting selected, the following prime was submitted on your behalf:

Added 142003 : 467885520^131072+1 (1136413 digits)

This prime was found on this workunit which will automatically show as a prime result after verification by the Largest Known Primes Database.

If you have any questions or concerns, please contact us and we will surely resolve any problems.

Once again, congratulations on your find! Thank you for participating in PrimeGrid.

PrimeGrid staff
 
I must be doing something terribly wrong with this Telephone challenge. 7 machines running and all report one day to 12 hours before the first completion. I see folks that completed two in the first hour lol.
 
Rollo said:
I must be doing something terribly wrong with this Telephone challenge. 7 machines running and all report one day to 12 hours before the first completion. I see folks that completed two in the first hour lol.
Click to expand...
Must have been double-checks or something. Full-length Seventeen or Bust WUs take a long time to run, even on the best machines!
 
In most PrimeGrid subprojects, including SoB-LLR, there are two types of tasks: "Main tasks" and "Proof tasks". Main tasks are big, proof tasks are small. Main tasks have names like "llrSOB_678901234_0", proof tasks have names like "llrSOB_678943210c_0". The c is for "check", because proof tasks are also known as check tasks.

Main tasks do the actual work of testing whether or not the candidate number in the workunit is prime (probable prime, actually). In case of SoB-LLR, the recent average CPU time of getting such a task done is ≈500 hours. (This is an average across all PrimeGrid participants who recently submitted SoB-LLR results. The average includes many old computers and many computers which are not configured well for SoB-LLR. Modern computers need a lot less than this average, if they are properly set up.¹ E.g. ≈1 day using 8 threads, which would be ≈200 hours.) While this task is running, the program performs some self-checks in order to detect and if possible correct errors due to overclocked cores or overclocked RAM or defective RAM or cosmic rays or whatnot. Plus, cryptographic "summaries" of the work done so far are computed periodically during the run time of the task. When the task is finally finished, the client does not only submit the actual result (is the candidate a probable prime, or if not, what's the so-called residue) but also several files with these cryptographic summaries.

Now, somebody has to verify whether or not this result is correct. That's way too much work to be done by the PrimeGrid server, therefore they let volunteers do it. In earlier times (before the crypto bits were added to the program), the server would simply let another participant do the very same computation as the first participant has already done. And if both participants computed that the candidate number is not a probable prime and both participant got the same residue, the PrimeGrid server would assume that both tasks were correctly computed and give credit to both. Or if both reported a probable prime, the PrimeGrid server would assume that both tasks were correctly computed, give credit to both, and either launch an independent primality test with a different algorithm or would let t5k.org perform such an independent test.

But that's in the past. Nowadays, the server takes the extra intermediate result files which the performer of the main task uploaded and turns them into a cryptographic challenge for another participant. That's the proof task. This cryptographic proof that the intermediate results and the final result fit together and were apparently computed correctly takes a lot less time than the main task (e.g. ≈25 CPU hours on a very old Xeon, for SoB-LLR proof tasks). When the PrimeGrid server receives the result of this quick proof task and it fits with the result of the main task, the PrimeGrid server assumes that both are correct, assigns credit to both (lots of credit to the main result, respectively little credit² to the proof result because the latter took less effort), and in the unlikely event that a probable prime was found reports it to t5k.org where an independent check is performed.

AFAIK.

________
¹) "Properly set up" = runs not more tasks at once than the processor caches can take; uses as many program threads as necessary for high CPU utilization; avoids program threads being scheduled in different last level cache domains in computers which have segmented last level CPU caches.
²) At this early point in the ongoing PrimeGrid challenge, all results which count towards the challenge are ones from proof tasks, with ≈1,100 points per result. It will take a while until we see first results of main tasks in the challenge; these will receive ≈140,000 points per result, or maybe ≈150,000 points even.
 
Last edited:
PS, the fast proof method is described in the paper An Efficient Modular Exponentiation Proof Scheme by Darren Li and Yves Gallot. (The paper covers the method after its initial implementation in the LLR2 program by Pavel Atnashev was generalized for adoption in the Genefer program.)

PPS, main task and corresponding proof task are usually performed by different computers.
The PrimeGrid server may occasionally assign main task and corresponding proof task to the same computers. This is still safe against defects or malicious tampering, thanks to how the proof files which come from the main task are transformed by the server into certificates which serve as input to the proof tasks. This is a nice bonus for projects in which only a small number of hosts is actively participating; project progress doesn't get blocked by lack of 3rd parties for validation. Only if the validation fails does the PrimeGrid server have to find another host to re-run another copy of the failed main task, and after that a proof task for the copied main task.
 
So, my machines running tasks estimated at 12 to 24 hour completion are just proof tasks and all of my machines are simply configured poorly to not be able to complete them in a matter of a couple of hours...got it.

I see a few here had early completions...would like to hear their input on the experience. My active machines are as follows...

(2) 9900X ( One of these is scheduled to finish a task in about 4 hours)
(2) 7950X
(1) 9950X
(1) 7800X3D
(1) 7950X3D
 
Last edited:
Day 0.5 stats:

Stats for team TeAm AnandTech
Rank___Credits____Username
11_____2166_______johnnevermind
23_____1082_______cellarnoise2
26_____1076_______Orange Kid

Rank__Credits____Team
5_____149012_____Czech National Team
6_____10006______Ukraine
7_____5674_______BOINC@AUSTRALIA
8_____4324_______TeAm AnandTech
9_____3426_______Antarctic Crunchers
10____2257_______Chinese Dream
11____2164_______Planet 3DNow!

Nobody's completed a full WU on our team yet. That's OK, it's a 10-day challenge.

Stats on the half-day because the race start time was inconvenient, and is getting more inconvenient. Remember to "spring forward" tonight!
 
Yay...#10 on the list. Guess it was a Main task taking 13 hours and 38 minutes to complete. I must be the only one participating for AF. Orange completed one about the same time as I did.

 
Last edited:
Rollo said:
So, my machines running tasks estimated at 12 to 24 hour completion are just proof tasks and all of my machines are simply configured poorly to not be able to complete them in a matter of a couple of hours...got it.

I see a few here had early completions...would like to hear their input on the experience. My active machines are as follows...

(2) 9900X ( One of these is scheduled to finish a task in about 4 hours)
(2) 7950X
(1) 9950X
(1) 7800X3D
(1) 7950X3D
Click to expand...
You need to set up you puters to have some kind of task "Pinning" script. So that these PG multithreaded tasks stay on just one chip on the AMD desktop cpus, or else the task may jump from chiplet to chiplet and that is much slower than staying within the same L3 cache and having the task also spill over into RAM like these tasks often do on the 32 mb cache chiplets anyway.

On your "X3d" chips you might be able to run 2? 4 threaded tasks on the 96mb L3 cache chiplets as these tasks will fit within the L3 cache. That gets complicated from what I have read, as I don't have any of these cpus..

On my Zen4 or Zen5 32mb L3 cache puters, I run 8 threaded tasks and use other software to "pin" the tasks to a specific 8 core chiplet. Process Lasso / instance balancer works great on Windows boxen. There are other windows and linux scripts that work well also. Just do some searching around.
 
Rollo said:
Yay...#10 on the list. Guess it was a Main task taking 13 hours and 38 minutes to complete. I must be the only one participating for AF. Orange completed one about the same time as I did.

Click to expand...

This is on of the few "We should just watch paint dry" challenges or I'd probably prefer to watch grass grow since I can do that outside in the shade and not inside this hot as heck place right now. It's March Mother Earth. Chill on the hot weather.

Luckily the weather is supposed to cool off a good bit in 3 - 4 days.
 
Skillz said:
This is on of the few "We should just watch paint dry" challenges or I'd probably prefer to watch grass grow since I can do that outside in the shade and not inside this hot as heck place right now. It's March Mother Earth. Chill on the hot weather.

Luckily the weather is supposed to cool off a good bit in 3 - 4 days.
Click to expand...

This is my first time, but from the looks of it I'm inclined to agree lol. Seems like the one with the most machines will be the winner from my initial perspective.
 
On computers which I lent to parsnip, there are currently tasks with FMA3 FFT lengths of 4M … 4608K (with 8 bytes for each FFT coefficient, that's 32.0 MB … 36.0 MB), and with AVX-512 FFT lengths of 4032K … 4320K (31.5 MB … 33.75 MB).

cellarnoise said:
On your "X3d" chips you might be able to run 2? 4 threaded tasks on the 96mb L3 cache chiplets as these tasks will fit within the L3 cache. That gets complicated from what I have read,
Click to expand...
It's obviously easy to do on a single-CCD CPU (5700X3D, 7800X3D, 9800X3D). On a dual-CCD CPU one could run two BOINC client instances, one with affinity to the X3D CCD and running 2 4-threaded tasks at once, and the other with affinity to the plain CCD running 1 8-threaded task at a time. — However, not only takes this a bit more configuration work, it also would mean that the duration of the tasks which get only 4 cores to work with gets rather long. I don't know if these downsides are justified by whatever lower multithreading overhead is there when going with 4 instead of 8 threads.

(Replace 8 and 4 by 6 and 3 for program thread count if a 6-core or 12-core CPU is involved.)

On any Zen 3…5 CPU, I would simply run 1 task on each CCD. However, I haven't done any actual measurements to verify this. And I have no Ryzens anyway, just one or another EPYC which have more memory throughput per CPU core combined with usually lower core clock (but higher memory latency, on the other hand).

StefanR5R said:
Here is one of several sources for simple scripts which pin Genefer tasks to those CPUs which belong to the same CCX:
xii5ku_AT in SETI.Germany's forum on December 17, 2023
Save the Windows script with a name like "gfn_affinity.ps1" (*.ps1 is for PowerShell scripts), edit the $cores=... line according to your CPU and according to whether or not the SMT threads shall be used, and then let it execute in parallel with BOINC.
Click to expand...
Editing the Powershell script for LLR2 is left as an exercise for the reader. The Bash script is already applicable to both LLR2 and Genefer.
 
I was all ready to post stats, then forgot.

Day 1.6 stats:

Rank___Credits____Username
6______3225208____w a h
7______3033074____crashtech
14_____2013707____ChelseaOilman
32_____867676_____Orange Kid
33_____846670_____mmonnin
40_____582210_____cellarnoise2
59_____303597_____johnnevermind
92_____150102_____Ken_g6
99_____139818_____waffleironhead
106____139296___10esseeTony

Rank__Credits____Team
1_____16462576___Czech National Team
2_____12276056___Romania
3_____11301363___TeAm AnandTech
4_____10426042___Antarctic Crunchers
5_____9264596____BOINC@AUSTRALIA
6_____8824646____SETI.Germany
 
StefanR5R said:
In case of SoB-LLR, the recent average CPU time of getting such a task done is ≈500 hours. (This is an average across all PrimeGrid participants who recently submitted SoB-LLR results. The average includes many old computers and many computers which are not configured well for SoB-LLR. Modern computers need a lot less than this average, if they are properly set up.¹ E.g. ≈1 day using 8 threads, which would be ≈200 hours.)
Click to expand...
The recent average average CPU time from Saturday (more than 500 h) did not yet include any returns from challenge participants. Right now the "edit PrimeGrid preferences" web page shows a recent average of 422 hours. That's not because workunits got smaller (they have only one way to go: bigger and bigger), but because folks join newer hosts during a challenge or/and tune their hosts better for the challenge subproject.

Incidentally, I happen to know that Xeon Broadwell-EP (top SKU with 22 cores) has a recent average of merely 416 hours CPU time. :-)

It is uncanny that these ten years old CPUs perform better than average, when taking this average across the whole PrimeGrid community. (Although I am expecting this recent average to still go further down over the course of the challenge. Perhaps considerably.) Even during the challenge, there are probably many hosts active which have their CPUs spending more time waiting on memory accesses than they spend time on actual Fast Fourier Transforms.
 
Day 2.5 stats:

Rank___Credits____Username
5______6805294____crashtech
7______5866120____w a h
11_____4617999____cellarnoise2
12_____4369191____ChelseaOilman
35_____1604680____Orange Kid
38_____1560855____mmonnin
62_____721877_____johnnevermind
93_____421222_____waffleironhead
105____293812___10esseeTony
136____151565_____[TA]Skillz
141____150102_____Ken_g6
168____131097_____Icecold

Rank__Credits____Team
1_____31698773___Czech National Team
2_____26693820___TeAm AnandTech
3_____20770511___Romania
4_____18724707___SETI.Germany
5_____17903095___Antarctic Crunchers
 
About the scripts which I linked to in post #68:
The IDs of logical processors are numbered differently in Windows and Linux. How to find out how logical CPUs are associated with SMT siblings, cache domains, sockets, and NUMA nodes?

On Linux, there is the command lscpu -e which is available out of the box on pretty much all Linux distributions. A more showy tool with a text UI and a graphical UI is lstopo, but it is likely not installed by default. It is part of a package called "hwloc" or something like that.

On Windows, I don't know of a way to do that out of the box. Does anybody? There is the external tool Sysinternals Coreinfo which suits the purpose. It has a text UI and a graphical UI:
https://learn.microsoft.com/en-us/sysinternals/downloads/coreinfo
 
Not much help to be had over at AF so I jumped ship to help you folks in the push.

Any tweaks I can employ to speed these up? Priority/Affinity have any effect in Task Manager?
 
Last edited:
Weeee!

Dear Primefinder,

Congratulations! Our records indicate that a computer registered by you has found a unique prime number. This computer is running BOINC, is attached to the PrimeGrid project, and is assigned to the Generalized Fermat Prime Search n=17 Mega (GFN-17-Mega). What makes this prime unique is that it's large enough to enter the Top 5000 List in The Largest Known Primes Database.

Since you have auto-reporting selected, the following prime was submitted on your behalf:

Added 142066 : 471646550^131072+1 (1136869 digits)

This prime was found on this workunit which will automatically show as a prime result after verification by the Largest Known Primes Database.

If you have any questions or concerns, please contact us and we will surely resolve any problems.

Once again, congratulations on your find! Thank you for participating in PrimeGrid.

PrimeGrid staff
 
You must log in or register to reply here.

TRENDING THREADS

Back
Top