The third challenge of the 2020 Series will be a 3-day challenge celebrating the 244th birthday of Sophie Germain, French mathematician and namesake of the Sophie Germain Prime Search subproject. The challenge will be offered on the SGS (LLR) application, beginning 1 April 12:00 UTC and ending 4 April 12:00 UTC.

By the beginning of the 19th century, Fermat's Last Theorem had already established itself as the most challenging problem in number theory. Mathematicians had merely succeeded in showing that there are no solutions to the following equations:
x³ + y³ = z³
x⁴ + y⁴ = z⁴
An infinite number of other equations remained, and mathematicians still had to demonstrate that none of these had any solutions. There was no progress until a young French woman reinvigorated the pursuit of Fermat's lost proof.

Marie-Sophie Germain was born on April 1, 1776 to a well-off family in Paris. From an early age, she became obsessed with number theory and the works of Euler and Newton. Despite discouragement from her parents and the gender norms of the era, she continued to pursue her passion, eventually earning wide renown through her correspondences with Lagrange, Legendre, Gauss, and others under a male pseudonym, M. LeBlanc.
Later work was finally submitted under her own name and on 8 January 1816, she became the first woman to win a prize from the Paris Academy of Sciences. While some consider her work lacking in rigor, almost all agree that it was from the lack of a formal education that was denied to her based on her gender.
Still, there's no question of her mathematical genius. Her work on Fermat's Last Theorem provided a foundation for mathematicians exploring the subject for hundreds of years after. She proved that there are no solutions to
xᵖ + yᵖ = zᵖ,
where p is a Sophie Germain prime number.

NOTE: If the candidate being tested is indeed prime, the task will take TWICE as long to complete. This is because it's checking for a twin prime!

Application builds are available for Linux 32 and 64 bit, Windows 32 and 64 bit and MacIntel. Intel and Zen2-based AMD CPUs with FMA3 capabilities (Haswell, Broadwell, Skylake, Kaby Lake, Coffee Lake, and Ryzen 3rd gen) will have a very large advantage, and Intel CPUs with dual AVX-512 (certain recent Intel Skylake-X and Xeon CPUs) will be the fastest.

ATTENTION: The primality program LLR is CPU intensive; so, it is vital to have a stable system with good cooling. It does not tolerate "even the slightest of errors." Please see this post for more details on how you can "stress test" your computer. Tasks on one CPU core will take about 20 minutes on fast/newer computers and 2 hours+ on slower/older computers. If your computer is highly overclocked, please consider "stress testing" it. Sieving is an excellent alternative for computers that are not able to LLR. :)

Highly overclocked Haswell, Broadwell, Skylake, Kaby Lake or Coffee Lake (i.e., Intel Core i7, i5, and i3 -4xxx or better) computers running the application will see fastest times. Note that SGS is running the latest AVX-512 version of LLR which takes full advantage of the features of these newer CPUs. It's faster than the previous LLR app and draws more power and produces more heat. If you have certain recent Intel Skylake-X and Xeon CPUs, especially if it's overclocked or has overclocked memory, and haven't run the new AVX-512 LLR before, we strongly suggest running it before the challenge while you are monitoring the temperatures.

Please, please, please make sure your machines are up to the task.

Multi-threading optimisation instructions

Those looking to maximise their computer's performance during this challenge, or when running LLR in general, may find this information useful.

Your mileage may vary. Before the challenge starts, take some time and experiment and see what works best on your computer.

If you have an Intel CPU with hyperthreading, either turn off the hyperthreading in the BIOS, or set BOINC to use 50% of the processors.

If you're using a GPU for other tasks, it may be beneficial to leave hyperthreading on in the BIOS and instead tell BOINC to use 50% of the CPU's. This will allow one of the hyperthreads to service the GPU.

The new multi-threading system is now live. This will allow you to select multi-threading from the project preferences web page. No more app_config.xml. It works like this:

In the preferences selection, there are selections for "max jobs" and "max cpus", similar to the settings in app_config.

Unlike app_config, these two settings apply to ALL apps. You can't chose 1 thread for SGS and 4 for SoB. When you change apps, you need to change your multithreading settings if you want to run a different number of threads.

There will be individual settings for each venue (location).

This will eliminate the problem of BOINC downloading 1 task for every core.

The hyperthreading control isn't possible at this time.

The "max cpus" control will only apply to LLR apps. The "max jobs" control applies to all apps.

If you want to continue to use app_config.xml for LLR tasks, you need to change it if you want it to work. Please see this message for more information.

Some people have observed that when using multithreaded LLR, hyperthreading is actually beneficial. We encourage you to experiment and see what works best for you.

NOTE: The countdown clock on the front page uses the host computer time. Therefore, if your computer time is off, so will the countdown clock. For precise timing, use the UTC Time in the data section at the very top, above the countdown clock.

Scoring Information

Scores will be kept for individuals and teams. Only tasks issued AFTER 1st April 2020 12:00 UTC and received BEFORE 4th March 2020 12:00 UTC will be considered for credit. We will be using the same scoring method as we currently use for BOINC credits. A quorum of 2 is NOT needed to award Challenge score - i.e. no double checker. Therefore, each returned result will earn a Challenge score. Please note that if the result is eventually declared invalid, the score will be removed.

At the Conclusion of the Challenge

We kindly ask users "moving on" to ABORT their tasks instead of DETACHING, RESETTING, or PAUSING.

ABORTING tasks allows them to be recycled immediately; thus a much faster "clean up" to the end of an LLR Challenge. DETACHING, RESETTING, and PAUSING tasks causes them to remain in limbo until they EXPIRE. Therefore, we must wait until tasks expire to send them out to be completed.

A prime number p is called a Sophie Germain prime if 2p + 1 is also prime. For example, 5 is a Sophie Germain prime because it is prime and 2 × 5 + 1 = 11, is also prime. These numbers are named after Marie-Sophie Germain, an extraordinary "French mathematician who made important contributions to the fields of differential geometry and number theory and to the study of Fermat's Last Theorem." (Wiki)

We'll be searching the form k*2^n-1. If it is prime, then we'll check k*2^n+1, k*2^(n-1)-1, & k*2^(n+1)-1. The opportunity to find SG's and Twins in the same subproject is appealing.

The Lucas-Lehmer-Riesel (LLR) test is a primality test for numbers of the form N = k*2^n − 1, with 2^n > k. Also, LLR is a program developed by Jean Penne that can run the LLR-tests. It includes the Proth test to perform +1 tests and PRP to test non base 2 numbers. See also:

We'll be searching the form k*2^n-1. If it is prime, then we'll check k*2^n+1, k*2^(n-1)-1, & k*2^(n+1)-1. The opportunity to find SG's and Twins in the same subproject is appealing.

Good that you edited the description! Because as has been discussed before, the "quad sieve" that was used (a long time ago) to filter the candidates for this SGS project, did not ensure that all of these three "related" forms are without a small factor. In particular, k*2^(n-1)-1 usually has a small factor, so that candidate was not considered by the sieve.

To show explicitly what I mean, here are ten recent SGS finds and a small factor of the related number (p-1)/2:

4991974083567*2^1290000-1 is prime, but 4991974083567*2^1289999-1 has the small factor 5.
4989137266155*2^1290000-1 is prime, but 4989137266155*2^1289999-1 has the small factor 1861.
4986988019907*2^1290000-1 is prime, but 4986988019907*2^1289999-1 has the small factor 5.
4986512304237*2^1290000-1 is prime, but 4986512304237*2^1289999-1 has the small factor 5.
4986020311725*2^1290000-1 is prime, but 4986020311725*2^1289999-1 has the small factor 11.
4983853372935*2^1290000-1 is prime, but 4983853372935*2^1289999-1 has the small factor 19.
4983600957657*2^1290000-1 is prime, but 4983600957657*2^1289999-1 has the small factor 5.
4982485133985*2^1290000-1 is prime, but 4982485133985*2^1289999-1 has the small factor 7.
4977027070095*2^1290000-1 is prime, but 4977027070095*2^1289999-1 has the small factor 13.
4974418692525*2^1290000-1 is prime, but 4974418692525*2^1289999-1 has the small factor 7.

Next time PrimeGrid does sieving for such a Sophie Germain/Twin subproject, please consider carefully if you want to include all three "related" candidates, p+2 and (p-1)/2 and 2p+1.

--

I am going to participate in this challenge with one "droplet" from The Science Cloud.

We'll be searching the form k*2^n-1. If it is prime, then we'll check k*2^n+1, k*2^(n-1)-1, & k*2^(n+1)-1. The opportunity to find SG's and Twins in the same subproject is appealing.

Good that you edited the description! Because as has been discussed before, the "quad sieve" that was used (a long time ago) to filter the candidates for this SGS project, did not ensure that all of these three "related" forms are without a small factor. In particular, k*2^(n-1)-1 usually has a small factor, so that candidate was not considered by the sieve.

Because really it was not a quad, it was triple sieve (3 of 4 sequences). We verified it some time ago and finally fixed this erroneous description.

There are different possible approaches for SGS sieving method, but it seems that triple sieve was a good compromise. Each sieve intersects with another by only 2%. If you want to add 3rd sequence (triple sieve), you must sieve "k" 50 times farther to get same number of candidates to test. Quad sieve again must be 50 times farther - "k" quickly rises to the skies and it becomes very difficult and slow to manage such sieve (very sparse candidates with huge gaps).

Tasks on one CPU core will take about 20 minutes on fast/newer computers and 2 hours+ on slower/older computers.

Is this really true for SGS? Even on my 5-year-old laptop CPU a task usually only takes about 12 - 15 minutes. A "fast/newer" computer should have no problem completing these tasks in 5 to 10 minutes.

I agree it's a bit misleading, perhaps the numbers could be tweaked a little. I guess it really comes down to what you define as "faster/newer" though.

I tried running SGS on a 7 years old 4700HQ (with FMA3) and it finished single-threaded in 16 minutes, however I know there are much older CPUs still being used here.

AMD fx-8350 runs these in about 25 minutes, but that is multi-threaded with 2 threads. Single-threaded will take a bit less than twice that long.

The 20 minutes mark should be read as faster CPUs will typically take under 20 minutes running single-threaded, while older (pre-AVX Intel and older AMD) CPUs will take longer than that with some running over 2 hours per unit.

Tasks on one CPU core will take about 20 minutes on fast/newer computers and 2 hours+ on slower/older computers.

Is this really true for SGS? Even on my 5-year-old laptop CPU a task usually only takes about 12 - 15 minutes. A "fast/newer" computer should have no problem completing these tasks in 5 to 10 minutes.

I agree it's a bit misleading, perhaps the numbers could be tweaked a little. I guess it really comes down to what you define as "faster/newer" though.

I tried running SGS on a 7 years old 4700HQ (with FMA3) and it finished single-threaded in 16 minutes, however I know there are much older CPUs still being used here.

AMD fx-8350 runs these in about 25 minutes, but that is multi-threaded with 2 threads. Single-threaded will take a bit less than twice that long.

The 20 minutes mark should be read as faster CPUs will typically take under 20 minutes running single-threaded, while older (pre-AVX Intel and older AMD) CPUs will take longer than that with some running over 2 hours per unit.

Since SGS sizes don't change much, the benches I did last year on my Core2Duo P8400 (mobile) could mean something. Runtimes were somewhere between 75 and 100 minutes, so it's actually not that bad. i5-2400 (FMA3) can finish these units (single-threaded) in 45 minutes, and my Zen1 can do roughly the same, sometimes faster at 40min.
____________
JonDan School Services
GFN-14: 50103906^16384+1
AP 21: 104383195353409757+142406036*23#*n for n=0..20

In general, is there any difference between a 50% CPU setting or running on 2 threads on a hyper-threaded machine? Should have planned ahead to do some testing but no time now.

If you run SGS single threaded (1 task per thread) then turning hyper threading off or setting BOINC to use 50% of your CPUs will give you very similar results. You will have two tasks running at once and two threads free.
You can also experiment with running a single task at once with two threads per task. On some older or lower end CPUs you might get better results with this configuration.

The common advice for SGS is to run one task per physical core on your CPU. So that would be where you would turn HT off or set BOINC to use 50% of the CPUs.
____________My Primes
Badge Score: 2*1 + 4*2 + 6*9 + 7*4 + 9*2 + 10*1 = 120

Since SGS sizes don't change much, the benches I did last year on my Core2Duo P8400 (mobile) could mean something. Runtimes were somewhere between 75 and 100 minutes, so it's actually not that bad. i5-2400 (FMA3) can finish these units (single-threaded) in 45 minutes, and my Zen1 can do roughly the same, sometimes faster at 40min.

We found 18 during the 1-day challenge in 2017. But how much has SGS progressed since then & how much sparser (if at all) have SGS primes become? Assuming linear growth for both I'm going to say 54 primes.

I'm sorry, but this confuses me a bit. Where do i "enable" HT? I only see one place relevant and that's primegrid preferences where I set the amount of threads per task.

If I want to do hyperthreading, I'll set my client to 50% AND change the value to more than "2"in primegrid preferences?

I'll be running the challenge on i9-7900x 10 cores/20threads.

To disable hyperthreading, you can either get into your system's BIOS and disable it altogether (advanced), or set your client's preferences to only use 50% of your CPU cores (easy).

Now I'm even more confused... If I set my clients preferences to 50%, the tasks finish quicker, but half of them are running at the same time. Which makes me think it's multi-threading or hyper-threading. But you are telling me that's how to turn OFF hyperthreading?

Let's say I keep hyperthreading ON in BIOS (I don't plan on doing anything in my BIOS)
And I leave my client on 100%, am I then hyperthreading? The number of tasks running at any given time is the same as the number of threads I can run on my CPU

I think numbermaniac meant, as all other PG ppl would mean, for that case you are avoiding using all the threads on a CPU.

But as SGS tasks are literally tiny, you shouldn't be multithreading...well only if you have a pre-skylake.

Let's say I keep hyperthreading ON in BIOS (I don't plan on doing anything in my BIOS)
And I leave my client on 100%, am I then hyperthreading?

Yes, you are. And technically in the *easy* way numbermaniac mentioned below you are still running hyperthreaded but using half the cores, on Linux I suppose this would be better because Linux (from what I've heard) is better at placing these tasks on the same cores.

Let's say on windows 10 you have a i9-9900X (10C/20T):
you keep the HT (hyperthreading) ON in BIOS
you set BOINC to use 50% of all cores
then you set PG to use all cores available for the SoB task you just downloaded.
Because BOINC/Win10 recognizes your 9900X as having 20 "CPUs", you would in this case be using 10 threads or "CPUs" as BOINC claims.
Now this is where windows and linux (supposedly) differs:
Windows assigns this job randomly to any of the 20 "CPUs", while Linux tries to put the jobs on complete cores, aka 5 cores, where windows might put the job on one thread each of the 10 cores.

In this challenge you might as well use 50% in BOINC and MT to 2 threads with PG prefs for linux, but for windows (or in general!) I'd recommend BIOS, cuz it's once and for all, and doesn't depend on the OS.
____________
JonDan School Services
GFN-14: 50103906^16384+1
AP 21: 104383195353409757+142406036*23#*n for n=0..20

I think numbermaniac meant, as all other PG ppl would mean, for that case you are avoiding using all the threads on a CPU.

But as SGS tasks are literally tiny, you shouldn't be multithreading...well only if you have a pre-skylake.

Let's say I keep hyperthreading ON in BIOS (I don't plan on doing anything in my BIOS)
And I leave my client on 100%, am I then hyperthreading?

Yes, you are. And technically in the *easy* way numbermaniac mentioned below you are still running hyperthreaded but using half the cores, on Linux I suppose this would be better because Linux (from what I've heard) is better at placing these tasks on the same cores.

Let's say on windows 10 you have a i9-9900X (10C/20T):
you keep the HT (hyperthreading) ON in BIOS
you set BOINC to use 50% of all cores
then you set PG to use all cores available for the SoB task you just downloaded.
Because BOINC/Win10 recognizes your 9900X as having 20 "CPUs", you would in this case be using 10 threads or "CPUs" as BOINC claims.
Now this is where windows and linux (supposedly) differs:
Windows assigns this job randomly to any of the 20 "CPUs", while Linux tries to put the jobs on complete cores, aka 5 cores, where windows might put the job on one thread each of the 10 cores.

In this challenge you might as well use 50% in BOINC and MT to 2 threads with PG prefs for linux, but for windows (or in general!) I'd recommend BIOS, cuz it's once and for all, and doesn't depend on the OS.

Ah, so when you say that I shouldn't multithread SGS, what you mean is. I shouldn't use more than 1 thread per core?

I have 10 Cores, Windows thinks I have 20. So I set my Boinc to use 50% -> 1 thread per core. But then I will have idle threads, right? and i wont be using all the potential of the CPU?

the LLR program used for SGS uses the whole resources of a core
using 2 threads on each core does not magically create additional resources
the most efficient approach is as has been described: Use 50% of CPUs

also, both Linux and Win10 do a reasonable job of allocating across cores sensibly
(at least on my machines)
____________

the LLR program used for SGS uses the whole resources of a core
using 2 threads on each core does not magically create additional resources
the most efficient approach is as has been described: Use 50% of CPUs

also, both Linux and Win10 do a reasonable job of allocating across cores sensibly
(at least on my machines)

Thank you, I'm just trying to wrap my head around what hyperthreading is and how it works :)

How do i monitor my "throughput" while I do the SGS?

If looking at the CPU time should be avoided, then how do I know what is most effective on my computer?

Use the PG website
Your Account page will show details of Tasks Returned in Last 24 Hours
If you click on your host within that table, you can see details of each individual task
which allows you to see what the impact of your settings is
____________

Try Prime95, but I don't have the details of how to do it right now, mackerel (I think) does.
____________
JonDan School Services
GFN-14: 50103906^16384+1
AP 21: 104383195353409757+142406036*23#*n for n=0..20

45 minutes before the challenge starts, and already 400,000 SGS tasks have been completed in the last 24 hours. (That's more than 4 per second - can you imagine the load the server is going through right now?)

How do I see the impact of my settings? Apart from run time and CPU time, there is little else to go on...

I think he just means that if you change your settings before a new task begins, and then look at the runtime of that task, you can see which of the options you were discussing earlier is the best for your computer.
____________
8915 × 2 ^ 1507177 + 1 -- 453,710 digit PPSE
6603 × 2 ^ 1411654 + 1 -- 424,955 digit PPSE (DC)

45 minutes before the challenge starts, and already 400,000 SGS tasks have been completed in the last 24 hours. (That's more than 4 per second - can you imagine the load the server is going through right now?)

If there's another burst once the challenge begins, it's going to be incredible.

welp for the server, what if a GFN15 challenge was run? *sneers* 1million tasks/day?
____________
JonDan School Services
GFN-14: 50103906^16384+1
AP 21: 104383195353409757+142406036*23#*n for n=0..20

...you can see details of each individual task
which allows you to see what the impact of your settings is

I think you have to guide me a bit more than that, boss.

How do I see the impact of my settings? Apart from run time and CPU time, there is little else to go on...

If you go to your home page and scroll down, you'll be met with this table:

The tasks column shows your daily throughput. From memory, with a chip like the 7900X, you're best off running 10x single-threaded SGS.

Thank you, I'm just trying to wrap my head around what hyperthreading is and how it works :)

Regarding hyperthreading: hyperthreading is where the CPU "splits" a CPU core into two logical threads. In some scenarios, this can be helpful for making the most out of your CPU. However, as Vato mentioned, the LLR program that we use will use a core to its maximum potential. If you were to use all 20 of your threads (so 20 tasks) on 10 actual cores, you'd be "overloading" each core and decreasing overall efficiency.

Um I think with HT on, you should be running 2 thread tasks

You can choose to run 2 threads per task, but I think that's a waste of throughput.

Also when I try Prime95, I get the following interesting results: running multithreaded is actually a little bit better than running single-threaded, so should I folow what P95 claims?
____________
JonDan School Services
GFN-14: 50103906^16384+1
AP 21: 104383195353409757+142406036*23#*n for n=0..20

That beat me. Well, I think it means I can process more tasks in a certain amount of time. But 100ms, I don't understand how that correlates with more tasks, 100ms/the time I process one SGS?
____________
JonDan School Services
GFN-14: 50103906^16384+1
AP 21: 104383195353409757+142406036*23#*n for n=0..20

Great! PG is a great place to learn to be patient ;) espeacially with slow computers XD
After checking, it seems that you aren't on there, check when you received those tasks, and set work cache in BOINC to 0.
____________
JonDan School Services
GFN-14: 50103906^16384+1
AP 21: 104383195353409757+142406036*23#*n for n=0..20

The current leading edge (i.e., latest work unit for which work has actually been sent out to a host) is k=5028389327997. The leading edge was at k=5025298185495 at the beginning of the challenge. Since the challenge started, the leading edge has advanced 0.06% as much as it had prior to the challenge!

:( I checked to make sure the issue date was April and i've completed (status valid) ~200, not showing up in stats list. I'm bummed.

Steve

(P.S. OK, I'm not that bummed :) but it would be nice to just show up)

It looks like all the tasks you have returned were issued before 12:00 UTC. The challenge starts at 12:00 UTC (not 00:00 UTC, I know I got confused by that myself).

It looks like you're running with a cache. It might help to set your BOINC cache to 0 days if you don't run projects that have intermittent work and abort all pending SGS tasks that have not started yet.

I'm crunching 4 * 4 on my 16 core machines. Even with that my 1st% is only 53%.
The old throughput vs 1st conundrum. :D

My 1950X is significantly quicker than my 3950X.
Same settings on both PC's but 855 tasks vs 678 in the last 24hrs. Seems strange....but whatever.
Perhaps its to do with the memory usage on the 1950X? No idea.

The bad news is we're only half a day in and we're already seeing the leaderboard generation take more than 15 minutes. That's a problem when it's scheduled to run every 15 minutes.

As of right now, it's only going to run once an hour. I expect this won't last very long, however. By the end of the challenge it may be running even less frequently. In fact, I can all but guarantee that we won't be able to create the leaderboards every hour for the length of the challenge.

____________
My lucky number is 75898524288+1(I am NOT an administrator anymore, so please don't PM me with questions. I can't help.)

The bad news is we're only half a day in and we're already seeing the leaderboard generation take more than 15 minutes. That's a problem when it's scheduled to run every 15 minutes.

As of right now, it's only going to run once an hour. I expect this won't last very long, however. By the end of the challenge it may be running even less frequently. In fact, I can all but guarantee that we won't be able to create the leaderboards every hour for the length of the challenge.

Can you turn off other stuff like firsts reporting? Just asking. I would rather have results posted than my first percentage.

Would performance increase at all if credits on the stats page weren't calculated at all until the end, and it was just sorted by the number of tasks returned? As far as I'm aware every SGS task is worth exactly the same number of credits unless you find a prime, and that's uncommon enough that just sorting by tasks should be a good enough idea of what's going on.

Would performance increase at all if credits on the stats page weren't calculated at all until the end, and it was just sorted by the number of tasks returned? As far as I'm aware every SGS task is worth exactly the same number of credits unless you find a prime, and that's uncommon enough that just sorting by tasks should be a good enough idea of what's going on.

That's a nice idea, but after some Googling and looking at the source code, it probably wouldn't make much of a difference. The only time it would save is a few log10 calls, and Google says log10 is O(log log n), so it wouldn't make much of a difference. It seems like the main bottleneck is the millions of results in the database. We also REALLY don't want to break something in the middle of a challenge.

The bad news is we're only half a day in and we're already seeing the leaderboard generation take more than 15 minutes. That's a problem when it's scheduled to run every 15 minutes.

As of right now, it's only going to run once an hour. I expect this won't last very long, however. By the end of the challenge it may be running even less frequently. In fact, I can all but guarantee that we won't be able to create the leaderboards every hour for the length of the challenge.

This reminds me of the early days where PPSE challenges would nearly take down the servers.
____________

The bad news is we're only half a day in and we're already seeing the leaderboard generation take more than 15 minutes. That's a problem when it's scheduled to run every 15 minutes.

As of right now, it's only going to run once an hour. I expect this won't last very long, however. By the end of the challenge it may be running even less frequently. In fact, I can all but guarantee that we won't be able to create the leaderboards every hour for the length of the challenge.

Can you turn off other stuff like firsts reporting? Just asking. I would rather have results posted than my first percentage.

That stuff on your home page is pretty light compared to the leaderboards generation code. Jim and Mike took a look at the code and it wasn't pretty. We're currently looking at 43 minutes to update the leaderboards. We will soon have to slow down the leaderboards generation rate again soon enough.

Another thing: the rate at which SGS tasks are being processed is getting faster as the challenge goes (good news!), but that also means it's ever more taxing for the server (slightly less good news).

Update on the challenge itself: 30 primes were found since the beginning of the challenge!

The current leading edge (i.e., latest work unit for which work has actually been sent out to a host) is k=5063112050817. The leading edge was at k=5025298185495 at the beginning of the challenge. Since the challenge started, the leading edge has advanced 0.75% as much as it had prior to the challenge!

SG primes are very very rare, and the last one was found in 2016, so... you get the message.
It's definitely not recommended to switch HT on, but if you can't switch it off, setting CPU to 50% is the best way and your assumption is correct if I remember everything correctly.
____________
JonDan School Services
GFN-14: 50103906^16384+1
AP 21: 104383195353409757+142406036*23#*n for n=0..20

If I got it right, a prime p is only a SG prime, if 2p + 1 is also prime. Were any of the 30 primes SG primes?

None of the 30 primes were SG primes. As Danny has mentioned, they are extremely rare.

Ok, thanks. I'd rather not diable HT because I assume it's useful in most cases other than primegrid crunching?

That's right, or at least it does not hurt in most other cases. Leaving HT on and using 50% CPU is almost the same that it shouldn't matter too much, as long as you don't run more tasks than the number of cores you have.
This is a setting you'll want to change in your BOINC client and not on the website. You usually want to leave your website preference to "No Limit", unless you know what you're trying to do.

Does that mean number of simultaneous tasks in the preferences should be set to 1/2 # of cores?

You want to use as many cores as you actually have on the CPU. Under Windows 8 and later, task manager should tell you how many actual cores you have (see image below). In my case, my CPU has 8 actual cores and no hyperthreads. For a CPU like an i3 2120, it has 2 actual cores and 4 hyperthreads. You'd want to only use 2. The throughput will stay the same or even increase, while at the same time the CPU will consume less power and stay cooler.

The current leading edge (i.e., latest work unit for which work has actually been sent out to a host) is k=5076469071957. The leading edge was at k=5025298185495 at the beginning of the challenge. Since the challenge started, the leading edge has advanced 1.02% as much as it had prior to the challenge!

Task Manager, as I've said before, can report GPU usage when you go to "Compute 1" or "Compute 0".
Same for CPU--no idea. Did you mean you think its load is too low or too high?

How to post a screenshot?

Either go to discord (not recommended for too many screenshots) or post a pic on your own website and use the "img" tag with the URL for the pic.
____________
JonDan School Services
GFN-14: 50103906^16384+1
AP 21: 104383195353409757+142406036*23#*n for n=0..20

About Compute 1, go to performance>GPU>and you see four small graphs
Click on the caption of any of them and switch it for compute 1.
____________
JonDan School Services
GFN-14: 50103906^16384+1
AP 21: 104383195353409757+142406036*23#*n for n=0..20

Setting the number of simultaneous tasks to the number of physical cores slowed down things for me. 4 simultaneous WUs took 33-34 min each, 2 WUs were 19 min each.

So in total it resulted in less WU/t.

I didn't run the 50% test for long, 6 or so WUs were finished, but it seems like this is not always the optimal setting?

It's always a "Your mileage may vary" thing. Running only as many tasks as you have physical cores is the general accepted consensus, but may not apply to everyone. Given that only 6 workunits were completed, I wouldn't say these results are conclusive, as the computer might have been running updates in the background or whatnot.
To accurately test throughput, one would typically run benchmarks with different configurations for few days before a challenge.

Setting the number of simultaneous tasks to the number of physical cores slowed down things for me. 4 simultaneous WUs took 33-34 min each, 2 WUs were 19 min each.

So in total it resulted in less WU/t.

Your statement of "physical cores" to be 4 is incorrect: The processor has got only two physical cores, each with two hardware threads.

But your finding that your processor had lower throughput with 4 concurrent tasks than with 2 is entirely expected:

Each SGS-LLR task needs to hold more than 1.0 MB of data in the processor caches, otherwise its performance will tank due to a high rate of accesses to main memory. The i3-2120 has got 3 MB level-3 cache, hence cannot support more than two simultaneous SGS-LLR tasks without heavy memory accesses.

Now the question remains whether 2 single-threaded tasks or 2 dual-threaded tasks give higher throughput. I know the answer for some other processor architectures ("it's a wash"), but not for Sandy Bridge.

Oops, my reading comprehension could stand improvement.

Did you compare 4 single-threaded tasks with 2 single-threaded tasks, or with 2 dual-threaded tasks?

Re: my prior statement on heavy memory access: On processors with high core count and very large cache, I actually have measured just a gradual decline in throughput as soon as the combined cache use of concurrent tasks began to exceed the cache size. Still, somewhat more than 4 MB hot data on a chip with 3 MB cache looks like too much. Though on second thought, it's merely 1 MB+ which needs to be pulled in and out all the time. That's tiny in comparison with most other LLR subprojects at PrimeGrid.

The current leading edge (i.e., latest work unit for which work has actually been sent out to a host) is k=5161155314187. The leading edge was at k=5025298185495 at the beginning of the challenge. Since the challenge started, the leading edge has advanced 2.70% as much as it had prior to the challenge!

When the challenge completes, we would prefer users "moving on" to finish those tasks they have downloaded, if not then please ABORT the WU's (and then UPDATE the PrimeGrid project) instead of DETACHING, RESETTING, or PAUSING.

ABORTING WU's allows them to be recycled immediately; thus a much faster "clean up" to the end of a Challenge. DETACHING, RESETTING, and PAUSING WU's causes them to remain in limbo until they EXPIRE. Therefore, we must wait until WU's expire to send them out to be completed.

Likewise, if you're shutting down the computer for an extended period of time, or deleting the VM (Virtual Machine), please ABORT all remaining tasks first. Also, be aware that merely shutting off a cloud server doesn't stop the billing. You have to destroy/delete the server if you don't want to continue to be charged for it.

All I changed from default was "use 50% of cores" instead of 100% (2 physical/4 logical cores i3). So I think it ran single threaded. With the limited test cases it seemed to slow things down.

Just to make sure: the setting you suggest is the "Max # of threads for each task"? So basically, set the number of cores to use to the percentage of physical cores vs logical. And "max # of threads" to 1/n (where n = #physicalCores/#logicalCores)? Spoken like the true mathematician I am not. ;)

As I don't have access to the client right now I probably cannot change the # of cores setting?

Apart from the SGS challenge, are those settings generally recommend? I see the HT warning for a lot of categories. I will do some more testing on monday in that case when I continue working towards the PPS silver badge. :)

All I changed from default was "use 50% of cores" instead of 100% (2 physical/4 logical cores i3). So I think it ran single threaded. With the limited test cases it seemed to slow things down.

Just to make sure: the setting you suggest is the "Max # of threads for each task"? So basically, set the number of cores to use to the percentage of physical cores vs logical. And "max # of threads" to 1/n (where n = #physicalCores/#logicalCores)? Spoken like the true mathematician I am not. ;)

As I don't have access to the client right now I probably cannot change the # of cores setting?

In your BOINC client, in Options -> Computing Preferences, set "Use at most ##% of the CPUs" to 50%.
Then, you would set "Max # of simultaneous PrimeGrid tasks" to "No Limit" and "Multi-threading: Max # of threads for each task" to 1 for SGS, irrespective of how many cores/threads you have.

That way, given that your system has n cores and 2n threads (assuming hyperthreading is left on), you would receive n tasks, each using 1 thread. You want to leave half the logical cores "unused".

Apart from the SGS challenge, are those settings generally recommend? I see the HT warning for a lot of categories. I will do some more testing on monday in that case when I continue working towards the PPS silver badge. :)

We suggest leaving half your logical cores free if you have hyperthreading on for all LLR tasks. On the other hand, sieving subprojects benefit from hyperthreading, and it does not seem to make much difference on CPU GFN tasks.

Just to make sure: the setting you suggest is the "Max # of threads for each task"?

Yes, I mean the setting which is called "Multi-threading: Max # of threads for each task" currently but should better be written as "Multi-threading: # of threads for each task", AFAICT.

Bur wrote:

So basically, set the number of cores to use to the percentage of physical cores vs logical. And "max # of threads" to 1/n (where n = #physicalCores/#logicalCores)? Spoken like the true mathematician I am not. ;)

As I don't have access to the client right now I probably cannot change the # of cores setting?

Note, I suggested this not as an optimization for your hardware, but for testing purpose (to learn more about where the throughput optimum of this Sandy Bridge i3 really is, and why). That is, I meant it more as something which could be tried if and when there is spare time, outside of a contest (unless you didn't run such a test already, which I now understand you haven't indeed).

That's because of the 1+ MB cache footprint per task, while this i3 has got 3 MB L3 cache.

Bur wrote:

Apart from the SGS challenge, are those settings generally recommend? I see the HT warning for a lot of categories. I will do some more testing on monday in that case when I continue working towards the PPS silver badge. :)

I meant it as a question, not as a recommendation, especially since I misunderstood your performance report at my first reading. :-)

I suspect these postings which recommend to avoid Intel Hyperthreading in LLR based PrimeGrid subprojects are coming mostly from people who never did any own measurements at all, or didn't measure in recent years, or applied poor testing methods. Proper advice on whether or not to use Hyperthreading needs to take the particular hardware and subproject into account, what the optimization goal is (throughput, run time, efficiency), and whether LLR runs exclusive or together with other workload.

Alas I have very little own test coverage for processors similar to yours, hence can't give a precise recommendation.

I'm super proud of my team managing to slot ourselves in at 18th place. Considering that we only had two active users when the challenge started, being able to return over 40,000 tasks and beat some powerhouse teams is a mammoth effort.

On a personal level, current stats are showing me as having finished on 999,994.13 credits. Whoops. Just one more task!

So what actually happened towards the end of the race? Why were we unable to get tasks for a while?

General consensus among admins is memory corruption. We saw mention of corruption in the apache logs and got lots of emails from the cron daemon with strange contents like "i: command not found" and extremely long lists of php warnings and errors from jobs that run nearly every minute. Since we have ECC RAM, this is very concerning. We rebooted the server and everything seems good again. The admins with more experience in this area (not me) will look into this more. The servers are a few years old at this point, but hopefully we can get some more time out of them.

The current leading edge (i.e., latest work unit for which work has actually been sent out to a host) is k=5176581829347. The leading edge was at k=5025298185495 at the beginning of the challenge. Since the challenge started, the leading edge has advanced 3.01% as much as it had prior to the challenge!