Welcome to the Solar Eclipse Challenge

The fifth Challenge of the 2018 Challenge series is a 3 day challenge to celebrate the Solar Eclipse on August 11th. The challenge is being offered on the Proth Prime Search (LLR) Project.

A solar eclipse occurs when the disk of the moon appears to cross in front of the disk of the sun. A total solar eclipse — like the one that took place on Aug. 21, 2017 — occurs when the disk of the moon blocks 100 percent of the solar disk. A partial eclipse occurs when the moon covers only part of the sun.

The Aug. 11, 2018 partial solar eclipse will touch many countries in the Northern Hemisphere. This animation shows the path of the moon's shadow.

The eclipse will start out over the North Atlantic Ocean and Greenland, moving north and east so that the shadow simultaneously moves toward Iceland, northern Europe and the northern polar regions. Continuing its path over the top of the planet, the shadow will be wide enough to cover most of northern Russia from east to west. It will then dip down into Mongolia, China and surrounding areas.

It will officially begin when the moon first appears to make contact with the sun's disk at 4:02 a.m. EDT (0802 UTC). Maximum eclipse will happen at 5:46 a.m. EDT (0946 UTC), when the eclipse is at magnitude 0.7361.

To participate in the Challenge, please select only the Proth Prime Search LLR (PPS) project in your PrimeGrid preferences section. The challenge will begin 10th August 2018 18:00 UTC and end 13th August 2018 18:00 UTC. Note that PPSE and PPS Mega do not count towards this challenge.

Application builds are available for Linux 32 and 64 bit, Windows 32 and 64 bit and MacIntel. Intel CPUs with AVX capabilities (Sandy Bridge, Ivy Bridge, Haswell, Broadwell, Skylake, Kaby Lake, Coffee Lake) will have a very large advantage, and Intel CPUs with FMA3 (Haswell, Broadwell, Skylake, Kaby Lake, Coffee Lake) 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 ~30mins 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 SR5 is running the latest FMA3 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 a Haswell, Broadwell, Skylake, Kaby Lake or Coffee Lake CPU, especially if it's overclocked or has overclocked memory, and haven't run the new FMA3 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.

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 10th August 2018 18:00 UTC and received BEFORE 13th August 2018 18: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 Proth Prime Search

The Proth Prime Search is done in collaboration with the Proth Search project. This search looks for primes in the form k*2^n+1. With the condition 2^n > k, these are often called Proth primes. This project also has the added bonus of possibly finding factors of "classical" Fermat numbers or Generalized Fermat numbers. As this requires PrimeFormGW (PFGW) (a primality-testing program), once PrimeGrid finds a prime, it is then tested on PrimeGrid's servers for divisibility.

Proth Search only searches for k<1200. PrimeGrid created an extension to that which includes all candidates 1200<k<10000 for n<5M. It is this extension which we call PPSE.

Initially, PrimeGrid's PPS project's goal was to double check all previous work up to n=500K for odd k<1200 and to fill in any gaps that were missed. We have accomplished that now and have increased it to n=3M. PG's LLRNet searched up to n=200,000 and found several missed primes in previously searched ranges. Although primes that small did not make it into the Top 5000 Primes database, the work was still important as it may have led to new factors for "classical" Fermat numbers or Generalized Fermat numbers. While there are many GFN factors, currently there are only 297 "classical" Fermat number factors known. Current primes found in PPS definitely make it into the Top 5000 Primes database.

For more information about "Proth" primes, please visit these links:

• Proth Prime - The Prime Glossary
  
• Proth Prime - Wolfram MathWorld
  
• Proth Number - Wikipedia

About Proth Search

The Proth Search project was established in 1998 by Ray Ballinger and Wilfrid Keller to coordinate a distributed effort to find Proth primes (primes of the form k*2^n+1) for k < 300. Ray was interested in finding primes while Wilfrid was interested in finding divisors of Fermat number. Since that time it has expanded to include k < 1200. Mark Rodenkirch (aka rogue) has been helping Ray keep the website up to date for the past few years.

Early in 2008, PrimeGrid and Proth Search teamed up to provide a software managed distributed effort to the search. Although it might appear that PrimeGrid is duplicating some of the Proth Search effort by re-doing some ranges, few ranges on Proth Search were ever double-checked. This has resulted in PrimeGrid finding primes that were missed by previous searchers. By the end of 2008, all new primes found by PrimeGrid were eligible for inclusion in Chris Caldwell's Prime Pages Top 5000. Sometime in 2009, over 90% of the tests handed out by PrimeGrid were numbers that had never been tested.

PrimeGrid intends to continue the search indefinitely for Proth primes.

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é
  

(Edouard Lucas: 1842-1891, Derrick H. Lehmer: 1905-1991, Hans Riesel: 1929-2014).
____________

Solar eclipses can occur at new moon only. Note that we have eclipses at consecutive new moons this time since 2018-Jul-13 was an eclipse as well (Wikipedia). /JeppeSN

Also, do not forget the great lunar eclipse coming in the middle between these two events, i.e. tomorrow. /JeppeSN

So a couple days ago I decided to switch to PPS LLR in preparation for the challenge. The throughput of PPS was rather uninspiring compared to the other projects I had been running. So I decided to look at how I was running PPS and did some quick testing on both my i5-4670 (DDR3-1600) and my i7-4790 (DDR3-1600). I started out with one task on four cores and was getting a lot of 1st's, but not a lot of total units done. So I tried two tasks on two cores each and found that while each unit was slower, overall throughput was higher. At that point I knew I had to try the traditional one task per core and see what happens. Then it only seemed prudent to run all three conditions on both CPUs to see if there was a difference.

These tests were all run using live units and the times are visually taken from the BOINC manager. So please take these results with more than a few grains of salt. haha

i7-4790 DDR3-1600 PPS LLR runtimes

Per Unit:
4c 1t = 10 minutes
2c 2t = 17 minutes
1c 4t = 37 minutes

Per two units:
4c 1t = 20 minutes
2c 2t = 17 minutes
1c 4t = 37 minutes

Per four units:
4c 1t = 40 minutes
2c 2t = 34 minutes
1c 4t = 37 minutes

i5-4670 DDR3-1600 PPS LLR runtimes

Per unit:
4c 1t = 10 minutes
2c 2t = 17 minutes
1c 4t = 40 minutes

Per two units:
4c 1t = 20 minutes
2c 2t = 17 minutes
1c 4t = 40 minutes

Per four units:
4c 1t = 40 minutes
2c 2t = 34 minutes
1c 4t = 40 minutes

PPS runs remarkably similarly on the two CPUs when running one or two tasks at a time. Bump up to four tasks at a time and the i5 starts to fall off.

If you have a Haswell CPU it looks like the best for speed is one task on four cores and if you want the best throughput it looks like the best is two tasks on two cores each.

Running four tasks at once was all around bad on both. It had the slowest speed per unit, lowest or second lowest throughput, and had the highest CPU temperature.

Different CPU families and different RAM speeds will drastically alter these results.

May whoever reads this find it informative or inspiring.
Happy prime finding!
____________
My Primes
Badge Score: 4*2 + 6*2 + 7*4 + 8*8 + 11*3 + 12*1 = 157

Interesting results. I should probably test same.

With the caution I haven't had the 1st coffee of the day yet, for the i7 I would have expected 4 tasks (one per core) to be best throughput as the work should fit on CPU cache comfortably, thus ram speed shouldn't really matter here. I note HT is on, and unless you've forced affinity, Windows scheduler can result in about 10% performance drop when running one task per core. If you turn off HT, or manually set affinity, you might see a small boost there. When multi-thread is enabled, it works a bit differently and you don't have to worry about it then.

On the i5, we're borderline running out of CPU cache, so there may be a performance impact one task per core, and thus 2 tasks of two threads each might offset that.

Interesting results. I should probably test same.

With the caution I haven't had the 1st coffee of the day yet, for the i7 I would have expected 4 tasks (one per core) to be best throughput as the work should fit on CPU cache comfortably, thus ram speed shouldn't really matter here.

Interesting results. I should probably test same.

With the caution I haven't had the 1st coffee of the day yet, for the i7 I would have expected 4 tasks (one per core) to be best throughput as the work should fit on CPU cache comfortably, thus ram speed shouldn't really matter here. I note HT is on, and unless you've forced affinity, Windows scheduler can result in about 10% performance drop when running one task per core. If you turn off HT, or manually set affinity, you might see a small boost there. When multi-thread is enabled, it works a bit differently and you don't have to worry about it then.

On the i5, we're borderline running out of CPU cache, so there may be a performance impact one task per core, and thus 2 tasks of two threads each might offset that.

You can still try setting manual affinity, but, with a GPU thrown in the mix I don't know how that would work. How much CPU time does AP take? When running multi-thread mode, it appears to set affinity in some way, so you don't need to do it manually.

Higher temps are an indicator of doing more work, although not necessarily useful work...

Interesting re temperatures. I was just going to leave mine on 1 task but will now benchmark 2 tasks to see which is cooler.

Ty Keith I'll give it a bash.

Literally just 1C difference.

Just done some testing on a 6700k.

Single -t4: 695s
Dual -t2: 940.5s
Quad -t1: 1553.9s

As suspected, running 4x single thread tasks is maximum throughput. Using -t2 speeds things up, but you lose efficiency in the process, and only does 82% of the work compared to single thread units. Running units with 4 threads, just no. That's only 55% the throughput.

Basically this doesn't seem to have changed at all from the last time I looked at it. I'd caution the difference between my testing and Keith's is that I'm NOT running any GPU tasks.

Before anyone says I used Skylake and Keith was on Haswell, I don't really expect that to be significant. The i5 vs i7 difference might come into it a little though, as the smaller cache of the i5 could start to impact things.

Before anyone says I used Skylake and Keith was on Haswell, I don't really expect that to be significant. The i5 vs i7 difference might come into it a little though, as the smaller cache of the i5 could start to impact things.

Just done some testing on a 6700k.

Single -t4: 695s
Dual -t2: 940.5s
Quad -t1: 1553.9s

On an i7, it shouldn't touch the ram even at one task per core. The work can be done out of L3 cache. Only on i5 might that become a factor.

As for time differences, I'd expect it to scale with clock, plus another 14% for -lake processors compared to Haswell when not ram limited as they added something to make it go faster.

The faster -t 4 result on Haswell has got my interest now... I have a Haswell quad I can excavate later and try on that.

Haswell test is still running, but I also ran a test on my 6600k. My theory was, the the smaller L3 cache may start to hinder it.

Single -t4: 695s
Dual -t2: 1072.5s
Quad -t1: 1767.8s

For total throughput, going one per core is still best. Like the 6700k before, running two units of two threads each was 82% the throughput. And one task of 4 threads, came out 64%, higher than on the 6700k yesterday of 55%.

What is interesting is if you look at it in terms of work done. The 6600k runs at 3.6 GHz all cores, stock, compared to 4.0 GHz on the 6700k. The 6700k should be 11% faster on clock.

Running 4 tasks, one per core, the 6700k was 15% faster. Running two tasks of two threads, it was similar at 14%. Maybe it is the cache in the case of 4 tasks, but it shouldn't be the case in 2 of 2, so I don't think I have a complete picture here. And the most interesting part... running one task of 4 threads, they were the same. The 6600k and 6700k both took the same median time to the second. My assumption here is that the code isn't able to scale well in that scenario, hence some limitation other than core clock dictates how fast it can go.

It should be really interesting to see how the Haswell results come out now...

Haswell results are in... and I'm not sure how to digest it.

Forget comparing across architectures for now... how does it scale?

CPU: i5-4570s (3.2 GHz all cores active)

Single -t4: 708s
Dual -t2: 1183.5s
Quad -t1: 2243.8s

Once again, running one task per core was highest throughput, with two of two close at 95%, and one task of 4 threads at 79%.

The one task with 4 threads is only 2% slower than either of the Skylake results. This is suggestive of some other limit in scaling this work to 4 threads.

I've previously come up with a value that Skylake is 14% faster per clock than Haswell, when not limited elsewhere e.g. ram bandwidth. Following allows for this 14% and the clock differences.

Running 4x -t1, it seems to scale within expectations, within a few % or so.

Running 2x -t2, I'm not sure what to do with this... it is over-performing compared to Skylake. I don't have an explanation for this. I would guess the lower running clock might be a contributing factor, and mask multi-thread scaling losses in some way, but I haven't tried to prove this or otherwise.

I tested an i7 7700K (with DDR4 3200 C14, and with a moderate negative AVX offset for the CPU clock defined in the BIOS), not only with the three configs that you chose, but with a few others more. It's an i7 after all, which has 8 logical CPUs, not 4. I came to a different conclusion than you; maybe because our systems differ, or maybe because I tested more configs.

Furthermore, while I haven't investigated what the variability between currently issued PPS-LLR WUs is, I found with several other LLR subprojects in the past that the variability between WUs is greater than the throughput difference between the best and next best #tasks x #threads configuration on a given machine. This is especially true on machines with higher core count. I therefore eliminate WU variability in my own throughput tests.

Interesting... your 4p x 1t is what I considered the optimal situation, but you got 4.4% more ppd on 4p x 2t. I don't have extensive or recent Linux experience but when I last looked at it, I think its scheduler did a better job than Windows.

On that note, I had seen hints of up to 2% improvement when using HT, but I decided that wasn't significant, and even if correct wasn't enough to offset the extra power it took. I never measured that power difference, but it was 10C hotter on the core on the system I was using. That is significant.

Prime95 does have a benchmark mode, and the interface in 29.x makes it easier to use than before. You can choose FFT lengths, thread and worker configurations, HT or not, and "complex FFTs". I don't know what the last one is, but I saw somewhere that might give more representative results for non-mersenne uses like LLR.

I have used it to build an observation model of how hardware works under various scenarios, but for sure there will be variables I have not accounted for, so it doesn't always match "real" PrimeGrid task behavior. While I'm fairly confident in the use case on quad core, maybe 6 core consumer level Intel CPUs, I'm less sure on Ryzen (CCX, infinity fabric, exclusive cache), Skylake-X (non-inclusive mesh cache), multi-socket configuration (NUMA or not), and any other high core count system (>8 or so).

As a rule of thumb, best throughput seems to be when the L3 cache (assuming inclusive) is filled but not exceeded by the running task(s).

While the Ryzen FPU might be comparatively slower than Intel's, it doesn't mean it will give errors if you push it. Double check there isn't another problem elsewhere that might be contributing...

Here's quick tests on my 8700K:
...
It seems running 3 tasks on 2 cores each is the sweet spot for PPS.

6 tasks on 1 core and 2 tasks on 3 cores are practically tied; 6 tasks runs a bit faster overall but 2 tasks use a little less CPU time.

On the last two 8700k results, if I assume the first one has HT on, it could be understandable. When running multi-thread at all, the scheduling seems to work better, but you may lose some performance from multi-thread scaling. One task per core with HT on can result in some loss of efficiency from scheduler unless you set affinity, or have HT turned off.

I haven't had time to test my 8086k on this at all and it will be set up at last minute when I get home from work...

and now to something completly different: GO! GO! GO!
Happy Challenge :)
____________
Sysadm@Nbg
my current lucky number: 113856050^65536 + 1
PSA-PRPNet-Stats-URL: http://u-g-f.de/PRPNet/

Any bets how many primes will be found during this short challenge? (A prime is counted if the task that first returned the prime result, is included in the challenge.) /JeppeSN

After 1+ days:

Challenge: Solar Eclipse
App: 10 (PPS-LLR)
(As of 2018-08-11 21:28:52 UTC)

238411 tasks have been sent out. [CPU/GPU/anonymous_platform: 238148 (100%) / 0 (0%) / 263 (0%)]

Of those tasks that have been sent out:

4311 (2%) came back with some kind of an error. [4311 (2%) / 0 (0%) / 0 (0%)]
148384 (62%) have returned a successful result. [148131 (62%) / 0 (0%) / 257 (0%)]
85727 (36%) are still in progress. [85723 (36%) / 0 (0%) / 6 (0%)]

Of the tasks that have been returned successfully:

51525 (35%) are pending validation. [51439 (35%) / 0 (0%) / 90 (0%)]
96791 (65%) have been successfully validated. [96624 (65%) / 0 (0%) / 167 (0%)]
40 (0%) were invalid. [40 (0%) / 0 (0%) / 0 (0%)]
28 (0%) are inconclusive. [28 (0%) / 0 (0%) / 0 (0%)]

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

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

Any bets how many primes will be found during this short challenge? (A prime is counted if the task that first returned the prime result, is included in the challenge.) /JeppeSN

We actually started betting on this yesterday in Discord. My vote was 5. There's 2 so far.

Actually, there's one more. So there's 3 now.

How do you go about changing how many tasks per core or how many cores per task (however its setup)?
I'm interested because I never knew you could change those values and I have a laptop with an i7-7700hq that runs extremely slow on task when it is useing all 8 cores.

Now there's 6 primes.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

After 2 days:


Challenge: Solar Eclipse
App: 10 (PPS-LLR)
(As of 2018-08-12 18:14:01 UTC)

372521 tasks have been sent out. [CPU/GPU/anonymous_platform: 372026 (100%) / 0 (0%) / 495 (0%)]

Of those tasks that have been sent out:

5793 (2%) came back with some kind of an error. [5793 (2%) / 0 (0%) / 0 (0%)]
277575 (75%) have returned a successful result. [277091 (74%) / 0 (0%) / 489 (0%)]
89211 (24%) are still in progress. [89202 (24%) / 0 (0%) / 6 (0%)]

Of the tasks that have been returned successfully:

63874 (23%) are pending validation. [63749 (23%) / 0 (0%) / 130 (0%)]
213520 (77%) have been successfully validated. [213161 (77%) / 0 (0%) / 359 (0%)]
117 (0%) were invalid. [117 (0%) / 0 (0%) / 0 (0%)]
64 (0%) are inconclusive. [64 (0%) / 0 (0%) / 0 (0%)]

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


We're up to 8 primes.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

With a couple of hours remaining in the challenge, it's time to remind everyone...

At the Conclusion of the Challenge

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. Thank you!
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

9 primes so far.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

Final results!


Challenge: Solar Eclipse
App: 10 (PPS-LLR)
(As of 2018-08-13 18:00:23 UTC)

521654 tasks have been sent out. [CPU/GPU/anonymous_platform: 520905 (100%) / 0 (0%) / 749 (0%)]

Of those tasks that have been sent out:

24374 (5%) came back with some kind of an error. [24374 (5%) / 0 (0%) / 0 (0%)]
437399 (84%) have returned a successful result. [436652 (84%) / 0 (0%) / 747 (0%)]
59008 (11%) are still in progress. [59004 (11%) / 0 (0%) / 2 (0%)]

Of the tasks that have been returned successfully:

56174 (13%) are pending validation. [56077 (13%) / 0 (0%) / 97 (0%)]
380860 (87%) have been successfully validated. [380210 (87%) / 0 (0%) / 650 (0%)]
279 (0%) were invalid. [279 (0%) / 0 (0%) / 0 (0%)]
86 (0%) are inconclusive. [86 (0%) / 0 (0%) / 0 (0%)]

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


9 PPS primes were found during the challenge. All were challenge tasks.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

The cleanup begins!

Solar Eclipse:
Aug-13: Solar Eclipse: 55801 tasks outstanding; 44514 affecting individual (293) scoring positions; 23540 affecting team (68) scoring positions.

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

Had a great Challenge.
Awesome photos of the Eclipse:
https://www.space.com/41464-partial-solar-eclipse-august-2018-photos.html
Eclipse from space:
https://phys.org/news/2018-08-image-partial-solar-eclipse-space.html

Full listing of Solar and Lunar Eclipses, and when the next one is visible from your nearest city:
https://www.timeanddate.com/eclipse/list.html

Solar Eclipse:
Aug-13: Solar Eclipse: 55801 tasks outstanding; 44514 affecting individual (293) scoring positions; 23540 affecting team (68) scoring positions.
Aug-14: Solar Eclipse: 25191 tasks outstanding; 18643 affecting individual (278) scoring positions; 7467 affecting team (40) scoring positions.

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

Solar Eclipse:
Aug-13: Solar Eclipse: 55801 tasks outstanding; 44514 affecting individual (293) scoring positions; 23540 affecting team (68) scoring positions.
Aug-14: Solar Eclipse: 25191 tasks outstanding; 18643 affecting individual (278) scoring positions; 7467 affecting team (40) scoring positions.

Still crunching here for the cleanup.

Challenge Cleanup:
Aug-13: Solar Eclipse: 55801 tasks outstanding; 44514 affecting individual (293) scoring positions; 23540 affecting team (68) scoring positions.
Aug-14: Solar Eclipse: 25191 tasks outstanding; 18643 affecting individual (278) scoring positions; 7467 affecting team (40) scoring positions.
Aug-15: Solar Eclipse: 18195 tasks outstanding; 12107 affecting individual (256) scoring positions; 1357 affecting team (29) scoring positions.

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

Challenge Cleanup:
Aug-13: Solar Eclipse: 55801 tasks outstanding; 44514 affecting individual (293) scoring positions; 23540 affecting team (68) scoring positions.
Aug-14: Solar Eclipse: 25191 tasks outstanding; 18643 affecting individual (278) scoring positions; 7467 affecting team (40) scoring positions.
Aug-15: Solar Eclipse: 18195 tasks outstanding; 12107 affecting individual (256) scoring positions; 1357 affecting team (29) scoring positions.
Aug-16: Solar Eclipse: 7545 tasks outstanding; 3279 affecting individual (188) scoring positions; 172 affecting team (17) scoring positions.
Aug-17: Solar Eclipse: 4290 tasks outstanding; 1269 affecting individual (125) scoring positions; 47 affecting team (7) scoring positions.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

Challenge Cleanup:
Aug-13: Solar Eclipse: 55801 tasks outstanding; 44514 affecting individual (293) scoring positions; 23540 affecting team (68) scoring positions.
Aug-14: Solar Eclipse: 25191 tasks outstanding; 18643 affecting individual (278) scoring positions; 7467 affecting team (40) scoring positions.
Aug-15: Solar Eclipse: 18195 tasks outstanding; 12107 affecting individual (256) scoring positions; 1357 affecting team (29) scoring positions.
Aug-16: Solar Eclipse: 7545 tasks outstanding; 3279 affecting individual (188) scoring positions; 172 affecting team (17) scoring positions.
Aug-17: Solar Eclipse: 4290 tasks outstanding; 1269 affecting individual (125) scoring positions; 47 affecting team (7) scoring positions.
Aug-18: Solar Eclipse: 1820 tasks outstanding; 291 affecting individual (61) scoring positions; 18 affecting team (3) scoring positions.
Aug-19: Solar Eclipse: 631 tasks outstanding; 40 affecting individual (15) scoring positions; 4 affecting team (2) scoring positions.
Aug-20: Solar Eclipse: 193 tasks outstanding; 7 affecting individual (4) scoring positions; 0 affecting team (0) scoring positions.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

The results are final!

Special Congratulations to:
● LookAS of Czech National Team for finding the first prime of the challenge 981*2^2622032+1
● JayPi of SETI.Germany for finding the second prime of the challenge 693*2^2623557+1
● UBT - Mikeejones of UK BOINC Team for finding the third prime of the challenge 807*2^2625044+1
● xii5ku of TeAm AnandTech for finding the fourth prime of the challenge 819*2^2627529+1
● zunewantan of Aggie The Pew for finding the fifth prime of the challenge 967*2^2629344+1
● JG4KEZ(Koichi Soraku) of BOINC@MIXI for finding the prime with the highest k of the challenge 1131*2^2629345+1
● vaughan of AMD Users for finding the prime with the lowest k of the challenge 465*2^2630496+1 that is also a Factor of xGF(2630493,7,4)!!!!
● Scott Brown of Aggie The Pew for finding the largest prime of the challenge 741*2^2634385+1
● eisler jiri of Czech National Team for finding the final prime of the challenge 813*2^2626224+1

Top 3 individuals:

1: zunewantan
2: xii5ku
3: Scott Brown

Top 3 teams:

1: Czech National Team
2: Aggie The Pew
3: SETI.Germany

Congratulations to the winners, and well done to everyone who participated.
See you at the Oktoberfest Challenge!

____________