! ! ! URGENT WARNING Re: Task Bunkering ! ! !

This subproject uses LLR2, which means dumping bunkers will be disastrous for the server. It will fill up the server's disk drive. That's really bad.

As a result, the server will stop accepting uploads. That will be bad for all users, of course, but it will be worse for the people who have been holding bunkers. You may miss out on uploading your entire bunker if we shut down uploads. The end result is that if we have to protect the server, people who are bunkering will be severely disadvantaged.

So we're asking everyone who has been bunkering tasks for our challenges to not do so in any challenge where we're using LLR2. This is to protect our ability to keep the server running during the challenge. But it's also in your best interest: you'll be the people hurt the most if uploads get suspended.

TL;DR: This will be our first LLR2 challenge, so please, please, please refrain from bunkering. Thank you!!!

That being said...


Welcome to Évariste Galois's Birthday Challenge!

The seventh challenge of the 2020 Series will be a 5-day challenge celebrating the 209th birthday of Évariste Galois, French mathematician and political activist. The challenge will be offered on the PPS-DIV (LLR) application, beginning 20 October 06:00 UTC and ending 25 October 06:00 UTC.

Évariste Galois (25 October 1811 – 31 May 1832) was a French mathematician and political activist. While still in his teens, he was able to determine a necessary and sufficient condition for a polynomial to be solvable by radicals, thereby solving a problem standing for 350 years. His work laid the foundations for Galois theory and group theory, two major branches of abstract algebra, and the subfield of Galois connections. He died at age 20 from wounds suffered in a duel.

For more about the life of Galois, check out this fantastic biography: https://mathshistory.st-andrews.ac.uk/Biographies/Galois/
Also stay tuned for the biopic starring Timothée Chalamet! (not really)

To participate in the Challenge, please select only the Fermat Divisor Search LLR (PPS-DIV) project in your PrimeGrid preferences section.

Note on LLR2 tasks: LLR2 has eliminated the need for a full doublecheck task on each workunit, but has replaced it with a short verification task. Expect to receive a few tasks about 1% of normal length.

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 2.5 hours on fast/newer computers and 5 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 is supported and IS recommended.

Those looking to maximize 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 a CPU with hyperthreading or SMT, either turn off this feature 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. Click here to set the maximum number of threads. 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.

Time zone converter:

The World Clock - Time Zone Converter

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 20th October 2020 06:00 UTC and received BEFORE 25th October 2020 06: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.

Please consider either completing what's in the queue or ABORTING them. Thank you. :)

About the Fermat Divisor Search

In mathematics a Fermat number, named after Pierre de Fermat who first studied them, is a positive integer of the form F_n = 2²ⁿ+1, where n is a nonnegative integer.
The first few Fermat numbers are 3, 5, 17, 257, 65537, 4294967297, 18446744073709551617, … (sequence A000215 in the OEIS).

Only five Fermat primes are known, and the Fermat numbers grow so quickly that it may be years before the first undecided case: F₃₃ = 2²³³+1 is shown prime or composite - unless we luck onto a divisor. Ever since Euler found the first Fermat divisor (divisor of a Fermat composite), factorers have been collecting these rare numbers.

The largest known prime Fermat divisor is the megaprime 13 * 2^5523860+1, discovered by PrimeGrid this January, which divides F_5523858 = 2^25523858+1. Will we break this record during the challenge?

Euler showed that every divisor of F_n (n greater than 2) must have the form k*2ⁿ⁺²+1 for some integer k. For this reason, when we find a large prime of the form k*2ⁿ+1 (with k small), we usually check to see if it divides a Fermat number. The probability of the number k*2ⁿ+1 dividing any Fermat number appears to be 1/k.

Any prime Generalised Fermat Number F_b,n = b²ⁿ+1 (with b an integer greater than one) is called a generalised Fermat prime (because they are Fermat primes in the special case b=2), Ribenboim (1996).
Riesel (1994) further generalised by defining Extended Generalised Fermat Numbers xGF_n,a,b = a²ⁿ+b²ⁿ.

In the Fermat Divisor Search we focus on special k's that are either small (generally gives high chance of dividing a Fermat number) or have special properties that makes them attractive.
First we searched k=19683 up to n=4M, (now complete).
Then we searched five additional k's, 1323 (even n only), 2187 (even n only), 3125, 3267 (even n only) and 3375, up to n=3.322M, (now complete).
Finally, we're currently searching 5<=k<=49 up to n=9M.

See also:

• The Top Twenty Fermat Divisors (The Prime Pages)
  
• The Top Twenty Generalized Fermat Divisors (bases 3,5,6,10,12) (The Prime Pages)
  
• Currently known Fermat divisors, sorted by k
  

What is LLR?

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:

• Lucas-Lehmer-Riesel test (WIKI)
  
• Download LLR by Jean Penné
  

What is LLR2?

LLR2 is an improvement to the LLR application developed by our very own Pavel Atnashev and stream. It utilizes Gerbicz checks to enable the Fast DoubleCheck feature, which will nearly double the speed of PrimeGrid's progress on the projects it's applied to. For more information, see this forum post.
____________

Time flies like an arrow. Fruit flies like a banana.

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.

Multi-threading....YES

Hyperthreading....NO

My mistake. Sorry. I often get the two confused.

I don't suppose there would be any way possible to get the short "proof" tasks to run on hyperthreads would there?

Or to only get the "proof" tasks? I've still got to read the thread about LLR2 to learn more about it.

I'm not trying to be mean or rude, but did you tell the whole world your server(s) have essentially a DoS vulnerability? Maybe fix the issue rather than plead the community to do the right thing, which I'm sure they will. However with that said, there are always malicious people out there. If there wasn't we wouldn't have Cyber Security.

I understand the resources required for a malicious person to submit enough bunkered tasks to fill the storage on your computing resources, but it could happen. How can the community help fix this problem? We need to buy more storage? Maybe I don't fully understand the issue here.

1.BOINC automatically uses all the threads available, which includes hyperthreads.

1.BOINC automatically uses all the threads available, which includes hyperthreads.

On software side, is there even a difference between a hyperthread and a normal thread? Hyperthreading just means two threads run on the same core using a scheduler. But it's not like one is a hyperthread, the other isn't.

That means as long as HT is on, even if BOINC is set to use only 50% of available CPUs, there will still be threads running alongside BOINC threads on the same core. That's not a bad thing per se, as the OS needs to run other tasks and HT allows to do that efficiently.

It's only a bad thing if the same task is split into so many threads that more than one thread of the same task runs on the same core.

1.BOINC automatically uses all the threads available, which includes hyperthreads.

On software side, is there even a difference between a hyperthread and a normal thread? Hyperthreading just means two threads run on the same core using a scheduler. But it's not like one is a hyperthread, the other isn't.

That means as long as HT is on, even if BOINC is set to use only 50% of available CPUs, there will still be threads running alongside BOINC threads on the same core. That's not a bad thing per se, as the OS needs to run other tasks and HT allows to do that efficiently.

It's only a bad thing if the same task is split into so many threads that more than one thread of the same task runs on the same core.

Not quite. Hyperthreading is a hardware resource - it duplicates the CPU registers of a core to allow 2 (software) threads to maintain execution state on the same core.

I disagree. A thread runs more efficiently if it is able to use data already found in the per-core cache. If a task flushes data from cache which is being used by it's co-resident alter-thread, that's a bad thing. This comment applies to any thread.

One acceleration strategy is to use CPU affinity to confine all non-BOINC tasks to a single core so that the BOINC work's cache is undisturbed. You will get less BOINC work done on that core and everything else will also run more slowly, but all the other cores will be fully busy with BOINC work. But O/S tasks are so limited in their CPU requirements compared to LLR that their CPU utilization is very low. The gains for BOINC are really by confining threads that consume CPU without doing much, like running javascript in a web browser (if your system is not dedicated to BOINC work).

My mistake. Sorry. I often get the two confused.

I don't suppose there would be any way possible to get the short "proof" tasks to run on hyperthreads would there?

Or to only get the "proof" tasks? I've still got to read the thread about LLR2 to learn more about it.

1.BOINC automatically uses all the threads available, which includes hyperthreads.
2.Alas, that's not possible. I'd really like another subproject with all the proof tasks but I don't think it'd be realistic. Probs I'd be the only one crunching them. ;)

I disagree. A thread runs more efficiently if it is able to use data already found in the per-core cache. If a task flushes data from cache which is being used by it's co-resident alter-thread, that's a bad thing. This comment applies to any thread.

But even if the data is still there for the other thread, isn't there a loss of efficiency due to overhead? Say you have two physical cores, what would be the advantage of running four threads on it instead of two?

1.BOINC automatically uses all the threads available, which includes hyperthreads.
2.Alas, that's not possible. I'd really like another subproject with all the proof tasks but I don't think it'd be realistic. Probs I'd be the only one crunching them. ;)

The problem with having such an option is that the double-check tasks are much shorter than the first-run tasks. What this means is that you'll end up having no tasks to run most of the time - your computer will just be sitting idle waiting for someone to complete a first-run task.

This would especially be the case if too many people decide to switch to the "double-check only" mode; if everyone switches to double checks only, who's doing the first-run tasks? There won't be any results to double-check!

1.BOINC automatically uses all the threads available, which includes hyperthreads.
2.Alas, that's not possible. I'd really like another subproject with all the proof tasks but I don't think it'd be realistic. Probs I'd be the only one crunching them. ;)

The problem with having such an option is that the double-check tasks are much shorter than the first-run tasks. What this means is that you'll end up having no tasks to run most of the time - your computer will just be sitting idle waiting for someone to complete a first-run task.

This would especially be the case if too many people decide to switch to the "double-check only" mode; if everyone switches to double checks only, who's doing the first-run tasks? There won't be any results to double-check!

Well people want to find primes, don't they? And by the DC subproject I meant DC of all subprojects. Surely people would be hunting for badges on at least SOME projects.?

The advantage of running 4 threads on 2 cores is that HT gives you the performance of roughly 3 cores. This means the same amount of work gets done sooner.

For Intel this is only true on newer machines than at least Core-i 4th gen.
On older ones using two hyper-threads per core slows down llr tasks.
Well, that's my experience.
Don't know about pre-ZEN Ryzen processors, but with ZEN it's full power on all threads as well.

As someone who still runs oldish hardware besides newer machines I consider this as quite important. ;-)

Configuring all that with app_config and PrimeGrid preferences is a little bit annoying, but we want the best experience for all machines, don't we?

What is bunkering? To keep first as high as possible I'm setup to only download one task at at ime.

Its like blood doping. People load up on work units then withhold sending them back until the race starts. Then they upload the work and get a boost to the team score.

It's within the rules so people do it. It can get quite complex for the diehards.

Its like blood doping. People load up on work units then withhold sending them back until the race starts. Then they upload the work and get a boost to the team score.

The advantage of running 4 threads on 2 cores is that HT gives you the performance of roughly 3 cores. This means the same amount of work gets done sooner.

Any bets how many DIV primes we will find during the five days? /JeppeSN

i'm going to be controversial and say NONE

although there will probably be one immediately before or after the challenge :-)
____________

Any bets how many DIV primes we will find during the five days? /JeppeSN

Can you explain what "bunkering" is?
I have no idea if I'm doing it or not.
Thanks!

Hello, I've been away from PrimeGrid for a bit due to only having a laptop available for some time. I recently acquired a Ryzen 3600XT, and I'm a little confused about the new multithreading settings.

Prime95 64-bit version 30.3, RdtscTiming=1
Timings for 384K all-complex FFT length (6 cores, 1 worker): 0.28 ms. Throughput: 3520.39 iter/sec.
Timings for 384K all-complex FFT length (6 cores, 2 workers): 0.41, 0.40 ms. Throughput: 4947.41 iter/sec.
Timings for 384K all-complex FFT length (6 cores, 3 workers): 0.64, 0.73, 0.60 ms. Throughput: 4630.21 iter/sec.
Timings for 384K all-complex FFT length (6 cores, 6 workers): 1.12, 1.14, 1.13, 1.14, 1.16, 1.13 ms. Throughput: 5287.88 iter/sec.
Timings for 384K all-complex FFT length (6 cores hyperthreaded, 1 worker): 0.30 ms. Throughput: 3300.74 iter/sec.
Timings for 384K all-complex FFT length (6 cores hyperthreaded, 2 workers): 0.37, 0.37 ms. Throughput: 5384.34 iter/sec.
Timings for 384K all-complex FFT length (6 cores hyperthreaded, 3 workers): 0.53, 0.60, 0.54 ms. Throughput: 5370.18 iter/sec.
Timings for 384K all-complex FFT length (6 cores hyperthreaded, 6 workers): 1.03, 1.03, 1.05, 1.03, 1.04, 1.04 ms. Throughput: 5784.13 iter/sec.

It says in this thread's first post that multithreading is recommended, yet I still seem to get better results running one task per core. Is this because of the large cache size of the new processors?

The result for the 6 cores, 3 workers test looks a little strange. Is this because of cache boundaries or something similar?

Also, I'm a bit puzzled by the apparent increase in performance when hyperthreading is used. Last time I checked, hyperthreading was always supposed to be disabled for LLR, but now I seem to get a ~10% performance increase with hyperthreading enabled, at least with the Prime95 benchmark. This also comes with a ~15% power consumption increase, however, and this processor already runs hot, even with a good cooler.

Are these results normal, specific to the new Ryzens, or is there something unusual with my setup?

With Ryzen it's fastest to run 1 task per core for this project.
What I believe the prime95 results mean is that it's also best to leave hyperthreading switched on with processor usage set at 50%.
People have also found it's faster to set the affinity for each task to a core: in this case a pair of processors: 0+1, 2+3 etc.

Are these results normal, specific to the new Ryzens, or is there something unusual with my setup?

It says in this thread's first post that multithreading is recommended, yet I still seem to get better results running one task per core. Is this because of the large cache size of the new processors?

The result for the 6 cores, 3 workers test looks a little strange. Is this because of cache boundaries or something similar?

Also, I'm a bit puzzled by the apparent increase in performance when hyperthreading is used. Last time I checked, hyperthreading was always supposed to be disabled for LLR, but now I seem to get a ~10% performance increase with hyperthreading enabled, at least with the Prime95 benchmark. This also comes with a ~15% power consumption increase, however, and this processor already runs hot, even with a good cooler.

This challenge may bring the DIV leading edge into the Top 100 domain. /JeppeSN

Looks like the error message is "too many exit(0)s". The program terminated with no error flag, more than once, without completing.

Have you tried resetting the project in BOINC Manager?

According to stats PPS-DIV currently does 6000 tasks a day, so it would be 3 weeks at that pace. Seems definitely doable during the challenge, rank 98 is pretty close as well with 2,005,115 digits.

According to stats PPS-DIV currently does 6000 tasks a day, so it would be 3 weeks at that pace. Seems definitely doable during the challenge, rank 98 is pretty close as well with 2,005,115 digits.

Already at 1970000 digits, so only 30,000 digits or 100,000 n to go. Apparently people were preparing for the challenge? Rank of 100+ is almost certain during challenge. Although T5K is so dominated by PG, that each prime we enter is likely to kick another one off... ;)

Now another question, the Xeon has 30MB of cache, am I correct that it is too many task to fit in the cache if I run 12 task, but memory being big enough to fit 6 task running on 2 cores?

Since many people discuss FFT size and cache and how many threads were optimal:

it seems like just using the Prim95 benchmark isn't sufficient? Do the results deviate from real world applications?
____________
1281979 * 2^485014 + 1 is prime ... no further hits up to: n = 5,700,000

I am already getting

Temporarily failed upload of llrDIV_325410570_0_r1373743283_10: transient HTTP error

because of those uploads, which are stuck, i dont get new wus.
some of my uploads are already on try 7-10.
are there any plans to fix this till tomorrow?

Greets from Germany
Felix

Really looking forward to this challenge.

Best of luck everyone. :)

Rolling start for me.
____________
My lucky number 1059094^1048576+1

I am already getting

Temporarily failed upload of llrDIV_325410570_0_r1373743283_10: transient HTTP error

because of those uploads, which are stuck, i dont get new wus.
some of my uploads are already on try 7-10.
are there any plans to fix this till tomorrow?

Greets from Germany
Felix

As far as we can tell, you're the only person with this problem. However, this is not a problem that leaves a clear record on the server. We only know about it when someone complains. None of us are having this problem. Is this happening on more than one computer, or are you aware of it happening to anyone else?

EDIT: Also, are all of the upload files blocked, or just some of them?

EDIT2: Right now, we think it's a network problem on your side. Possibly a router with an incorrectly configured MTU, or blocked lost ICMP. If you're only crunching at PrimeGrid for the challenges, you would not have seen this before because this is the first challenge using LLR2, which uses sends much larger files back to the server.

Thanks for your reply,

this problem only occurs on Primegrid, all other projects work without any issues.
most of the files upload directly, but about 1/4 of the uploads get stuck, resulting on wus, which won't report -> no new wus, because to many wus uploading.
i just started primegrid again after a few months, first time with LLR2.
321sv works fine too.
i never had this issue before on primegrid. This problem occured once at climateprediction.net, because the server couldnt handle the amount of uploads.

Networking should be stable, never had any issues here.

Greets from Germany
Felix

it seems like just using the Prim95 benchmark isn't sufficient? Do the results deviate from real world applications?

Felix][quote][quote]I am already getting

Temporarily failed upload of llrDIV_325410570_0_r1373743283_10: transient HTTP error

Stats are currently broken, a fix is on the way. Please wait for few hours until it's done.

This is our first LLR2 challenge and a bug in new code slips somehow through testing.

Maybe too early to consider, but I guess the clean-up phase after the challenge should be nice and quick with LLR2? /JeppeSN

[SG wrote:

Felix][quote][quote]I am already getting

Temporarily failed upload of llrDIV_325410570_0_r1373743283_10: transient HTTP error

Felix,

I have good news, and bad news.

The good news is I found a second person with the same problem. One of our admins, in fact.

So it's not you.

The bad news is he's also in Germany.

The really bad news is he's on the same ISP as you.

The problem appears to be your ISP, or at least it's somewhere in their network.

No such problem here in Saarbrücken (Germany). ISP is Telekom Deutschland.

[SG wrote:

Felix][quote][quote]I am already getting

Temporarily failed upload of llrDIV_325410570_0_r1373743283_10: transient HTTP error

Felix,

I have good news, and bad news.

The good news is I found a second person with the same problem. One of our admins, in fact.

So it's not you.

The bad news is he's also in Germany.

The really bad news is he's on the same ISP as you.

The problem appears to be your ISP, or at least it's somewhere in their network.

No such problem here in Saarbrücken (Germany). ISP is Telekom Deutschland.

Sorry, I should have mentioned which ISP. Both people with upload problems use Vodaphone.

Thanks Michael,

I already thought about this, maybe they don't have any bandwith on the internet excanges free or something like this.

i think there is not much what i can do about this.

First prime!

https://primes.utm.edu/primes/page.php?id=131342
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

From PrimeGrid Discord:
Tuesday October 20, 2020 13:22:13 UTC: 39*2^6648997+1 is a DIV prime (2,001,550 digits) found by tng and double-checked by an internal process. https://www.primegrid.com/workunit.php?wuid=681048112