Welcome to the Halloween Challenge!

The seventh Challenge of the 2018 Challenge series is a 7 day challenge to celebrate Halloween. The challenge is being offered on the Woodall Prime Search (LLR) application.

Halloween or Hallowe'en (a contraction of Hallows' Evening), also known as Allhalloween, All Hallows' Eve, or All Saints' Eve, is a celebration observed in a number of countries on 31 October, the eve of the Western Christian feast of All Hallows' Day. It begins the three-day observance of Allhallowtide, the time in the liturgical year dedicated to remembering the dead, including saints (hallows), martyrs, and all the faithful departed.

It is widely believed that many Halloween traditions originated from ancient Celtic harvest festivals, particularly the Gaelic festival Samhain; that such festivals may have had pagan roots; and that Samhain itself was Christianised as Halloween by the early Church. Some believe, however, that Halloween began solely as a Christian holiday, separate from ancient festivals like Samhain.

Halloween activities include trick-or-treating (or the related guising), attending Halloween costume parties, carving pumpkins into jack-o'-lanterns, lighting bonfires, apple bobbing, divination games, playing pranks, visiting haunted attractions, telling scary stories, and watching horror films. In many parts of the world, the Christian religious observances of All Hallows' Eve, including attending church services and lighting candles on the graves of the dead, remain popular, although elsewhere it is a more commercial and secular celebration. Some Christians historically abstained from meat on All Hallows' Eve, a tradition reflected in the eating of certain vegetarian foods on this vigil day, including apples, potato pancakes, and soul cakes.

To participate in the Challenge, please select only the Woodall Prime Search LLR (WOO) project in your PrimeGrid preferences section. The challenge will begin 24th October 2018 23:59:59 UTC and end 31st October 2018 23:59:59 UTC.

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 ~2 days on fast/newer computers and 7+ days 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 WOO 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.

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.

  
  

• Use LLR's multithreaded mode. It requires a little bit of setup, but it's worth the effort. Follow these steps:
  
  
  
  • Create a app_config.xml file in the directory C:\ProgramData\BOINC\projects\www.primegrid.com\ (or wherever your BOINC data directory is located). For a quad core CPU, the file should contain the following contents. Change the two occurrences of "4" to the number of actual cores your computer has.
    
    
    <app_config> <app_version> <app_name>llrWOO</app_name> <cmdline>-t 4</cmdline> <avg_ncpus>4</avg_ncpus> </app_version> </app_config>
    
    
  • After creating the file, click on "Options/Read config files". You should then restart BOINC or reboot.
    
  • The first time BOINC downloads an WOO task, it may act a little strange and download 4 tasks instead of 1. The run times on this first set of tasks may look a bit strange too. This is normal. This will also occur anytime BOINC downloads more than one task at a time. This can be avoided by setting "Use at most [ 1 ] % of the CPUs" before you download CUL tasks. After one task was downloaded, increase the percentage.
    
  • 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 24th October 2018 23:59:59 UTC and received BEFORE 31st October 2018 23:59:59 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 Woodall Prime Search

Woodall Numbers (sometimes called Cullen numbers 'of the second kind') are positive integers of the form Wn = n*2^n-1, where n is also a positive integer greater than zero. Woodall numbers that are prime are called Woodall primes (or Cullen primes of the second kind).

The Woodall numbers Wn are primes for the following n:

2, 3, 6, 30, 75, 81, 115, 123, 249, 362, 384, 462, 512, 751, 822, 5312, 7755, 9531, 12379, 15822, 18885, 22971, 23005, 98726, 143018, 151023, 667071, 1195203, 1268979, 1467763, 2013992, 2367906, 3752948, and 17016602 and composite for all other n less than 17337441.

It is conjectured that there are infinitely many such primes. Currently, PrimeGrid is testing for Woodall primes in the n=17M - n=18M level (M=mega, 10^6). The last 4 Woodall primes found by PrimeGrid are:

2013992*2^2013992−1 (Lasse Mejling Andersen): official announcement | Prime Pages Entry
2367906*2^2367906−1 (Stephen Kohlman): official announcement | Prime Pages Entry
3752948*2^3752948−1 (Matthew J. Thompson): official announcement | Prime Pages Entry
17016602*2^17016602−1 (Diego Bertolotti): official announcement | Prime Pages Entry

For more information on Woodall numbers, please visit the following sites:

• Woodall Number - The Prime Glossary at the Prime Pages
  
• Top 20 Woodall Primes - Top Twenty at the Prime Pages
  
• Woodall Number - MathWorld--A Wolfram Web Resource
  
• Woodall Number - Wikipedia
  

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).
____________

Good luck to everyone!
We've already found one Woodall prime this year. Will luck strike twice?
____________
My Primes
Badge Score: 4*2 + 6*2 + 7*4 + 8*8 + 11*3 + 12*1 = 157

You can ignore that message.

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

After day 1:


Challenge: Halloween
App: 3 (WOO-LLR)
(As of 2018-10-26 00:20:47 UTC)

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

Of those tasks that have been sent out:

734 (9%) came back with some kind of an error. [734 (9%) / 0 (0%) / 0 (0%)]
655 (8%) have returned a successful result. [655 (8%) / 0 (0%) / 0 (0%)]
6342 (82%) are still in progress. [6342 (82%) / 0 (0%) / 0 (0%)]

Of the tasks that have been returned successfully:

552 (84%) are pending validation. [552 (84%) / 0 (0%) / 0 (0%)]
103 (16%) have been successfully validated. [103 (16%) / 0 (0%) / 0 (0%)]
0 (0%) were invalid. [0 (0%) / 0 (0%) / 0 (0%)]
0 (0%) are inconclusive. [0 (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=17651595. The leading edge was at n=17528522 at the beginning of the challenge. Since the challenge started, the leading edge has advanced 0.70% as much as it had prior to the challenge!
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

which one. i see a few of them in check list

Day 2:


Challenge: Halloween
App: 3 (WOO-LLR)
(As of 2018-10-27 01:11:02 UTC)

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

Of those tasks that have been sent out:

960 (10%) came back with some kind of an error. [960 (10%) / 0 (0%) / 0 (0%)]
1927 (20%) have returned a successful result. [1927 (20%) / 0 (0%) / 0 (0%)]
6691 (70%) are still in progress. [6691 (70%) / 0 (0%) / 0 (0%)]

Of the tasks that have been returned successfully:

1442 (75%) are pending validation. [1442 (75%) / 0 (0%) / 0 (0%)]
476 (25%) have been successfully validated. [476 (25%) / 0 (0%) / 0 (0%)]
1 (0%) were invalid. [1 (0%) / 0 (0%) / 0 (0%)]
8 (0%) are inconclusive. [8 (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=17678083. The leading edge was at n=17528522 at the beginning of the challenge. Since the challenge started, the leading edge has advanced 0.85% as much as it had prior to the challenge!
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

Conventional wisdom (for challenges without "bunkering" allowed) has everyone starting to crunch as soon as possible after the beginning of the challenge, and running tasks continuously until the end of the challenge. This strategy works best for crunchers having the aggregate CPU power to rank in the top 50 or so on the individual leaderboard, and in general for everyone when tasks have relatively short runtimes.

Otherwise, other strategies will maximize individual score and rank in challenges having long-running tasks like this one.

Strategy 1: wait

Wait a period of time from the start of the challenge before retreiving the first challenge tasks to be crunched. This works because the majority of tasks are handed out by the server in order of increasing score, and below the top 50 competitors, individuals fall into peer groups who will complete the same number of tasks during a challenge. Those who crunch higher-scoring tasks on average will rank higher within their peer group.

However, the waiting period must not be so long that fewer tasks will be completed within the challenge time frame. A corollary is that a machine can maximize its contribution to a challenge score without needing to enter a challenge near the beginning. There is usually sufficient slack time to complete other work in progress without aborting that work to enter a challenge at the beginning.

Another benefit of waiting is that the high-volume crunchers will be first to consume the older part of the task queue (from before additional tasks were added for the challenge), which contains the lower-scoring recycled tasks that previously timed out or were aborted.

Strategy 2: abort recycled tasks

A related strategy is to ensure that you are always crunching fresh tasks rather than lower-scoring recycled tasks. For this you must "actively manage" your assigned workload, by aborting recycled tasks. Since information on tasks in progress is suppressed pending completion, you must check the name of each task. Recycled tasks are those having a number following the rightmost _ which is (usually) something other than 0 or 1. For instance, llrWOO_307159609_2 is a recycled task, so it will have a lower score at completion than a fresh task fetched at around the same time.

Once again there is a caveat. If the task you intend to abort has been crunching for a significant period of time, then you will be better off letting it go to completion. Otherwise you might end up with a lower number of tasks completed by the end of the challenge.

For both these strategies, the total challenge time sacrificed by a CPU (in the initial waiting period, or completely lost due to active task management) must not exceed the fastest multithreaded runtime of a single task on that CPU. For Woodall tasks, there is a lot of time to play with because single task runtimes can exceed several hours.

Strategy 3: slow and steady

Naturally, the most important strategy you can have is to ensure that all the work done by your CPUs are of good quality. Invalid results due to CPU overheating are wasted energy and CPU time. So clean out the dust inside the computer and blocking the vents, and reduce the clock speed if necessary. See the first post.

Day 3:


Challenge: Halloween
App: 3 (WOO-LLR)
(As of 2018-10-28 01:58:01 UTC)

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

Of those tasks that have been sent out:

1258 (11%) came back with some kind of an error. [1258 (11%) / 0 (0%) / 0 (0%)]
3369 (30%) have returned a successful result. [3369 (30%) / 0 (0%) / 0 (0%)]
6573 (59%) are still in progress. [6573 (59%) / 0 (0%) / 0 (0%)]

Of the tasks that have been returned successfully:

2175 (65%) are pending validation. [2175 (65%) / 0 (0%) / 0 (0%)]
1162 (34%) have been successfully validated. [1162 (34%) / 0 (0%) / 0 (0%)]
5 (0%) were invalid. [5 (0%) / 0 (0%) / 0 (0%)]
27 (1%) are inconclusive. [27 (1%) / 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=17698926. The leading edge was at n=17528522 at the beginning of the challenge. Since the challenge started, the leading edge has advanced 0.97% as much as it had prior to the challenge!
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

Michael & Roger,

Here is a suggestion to alter the challenge scoring algorithm by dividing challenges into "sprints" and "marathons". Longer-running challenges, especially those with longer-running tasks, would operate as marathons and shorter challenges as sprints.

Sprint challenges would have fixed starting and ending times (as they do now).

For marathon challenges, each participant establishes their individual starting time when their first challenge task is fetched during the "starting interval", say on a particular date (UTC). If they fetch their first challenge task after the end of the starting interval, then their start time is set at the end of the starting interval.

For this Halloween Challenge, the beginning of the start interval would have been 1 day earlier than the actual current starting time. This would allow each participant to start a marathon challenge at a time which is most convenient to them.

A challenger's individual deadline is then set at a fixed time offset from the individual start time (e.g. 7 days), and it would be no later than that fixed offset from the end of the starting interval (i.e. the actual deadline for the current challenge).

Naturally this would make setting up challenge score accounting a bit more challenging.
But you enjoy some kinds of challenges, n'est-ce pas?

A better strategy is to determine how many cores to use per task for max throughput in the allotted time.

Hello everyone,

does everyone else experience very inconsistent run times, while the CPU times for the Work Units is more or less the same.

Check my computers for this:

http://www.primegrid.com/hosts_user.php?userid=63648

I use all cores on each CPU (usually 4) to run one WU. There is no other Boinc Application or program running in the background. So i am very confused why my run times are so inconsistent. I am using the app_config file as posted in the thread.

Thanks for any help.

How can you make sure, that only one WU is downloaded per request, when already one is in progess? Is it even worth the trouble?

- The L3 cache that your 4-core CPUs have is a lot smaller than llrWOO tasks like.

Perhaps this is true on Windows. I neglected to perform proper measurements for llrWOO, but based on what I know from other LLR based subprojects, I suspect that the optimum thread count is larger on Linux.

I run several Broadwell LGA 1150 CPUs which have a 4th level cache of 128MB. They are very fast, and perform better then any other quad core cpu with even faster frequencies. But the smaller the project the less of an impact it has.
There might be improved times of the huge L3 caches of the high core count cpus, when you run one WU on all cores, but i have no idea how much cache memory it takes for the llrWOO tasks.

After 4 days:


Challenge: Halloween
App: 3 (WOO-LLR)
(As of 2018-10-29 00:25:42 UTC)

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

Of those tasks that have been sent out:

1487 (11%) came back with some kind of an error. [1487 (11%) / 0 (0%) / 0 (0%)]
4799 (37%) have returned a successful result. [4799 (37%) / 0 (0%) / 0 (0%)]
6766 (52%) are still in progress. [6766 (52%) / 0 (0%) / 0 (0%)]

Of the tasks that have been returned successfully:

2707 (56%) are pending validation. [2707 (56%) / 0 (0%) / 0 (0%)]
2043 (43%) have been successfully validated. [2043 (43%) / 0 (0%) / 0 (0%)]
10 (0%) were invalid. [10 (0%) / 0 (0%) / 0 (0%)]
39 (1%) are inconclusive. [39 (1%) / 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=17724668. The leading edge was at n=17528522 at the beginning of the challenge. Since the challenge started, the leading edge has advanced 1.12% as much as it had prior to the challenge!
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

You can also set the preferences to 25% "use CPUs", that way it will only request 1 task when running dry (if 4 cores).

There are, so far, 14 results reporting a new Woodall prime.

However, as with all numbers, such as Woodall, where b=2 and c=-1, computation errors often result in a false prime result, and there's strong reasons to suspect that all 14 primes are errors.


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

I guess it will take a while to manually check those false positive...
____________
My stats

I guess it will take a while to manually check those false positive...

Composite wrote:

Conventional wisdom...

There are, so far, 14 results reporting a new Woodall prime.

However, as with all numbers, such as Woodall, where b=2 and c=-1, computation errors often result in a false prime result, and there's strong reasons to suspect that all 14 primes are errors.

So for forms k*2^n - 1, it appears that hardware errors sometimes lead to a particular wrong residue/result, namely: 0 == 'Is prime!'.

There must be a small probability (epsilon squared) that both tasks (sent out for one workunit) return the same wrong result, 0 == 'Is prime!'.

Historically, when BOINC finds that both tasks of one workunit (with b=2; c=-1) agree it is a prime, what has been the empirical odds this was due to two bad computers accidentally agreeing on the wrong conclusion (rather than a genuine prime discovery)?

/JeppeSN

There must be a small probability (epsilon squared) that both tasks (sent out for one workunit) return the same wrong result, 0 == 'Is prime!'.

Thanks. Interesting.

It should not take too long for someone with a non-overclocked processor to run through all the finds in SGS, as a triple check. But the probability that a "prime" can be removed by such an effort, must be microscopic.

/JeppeSN

Thanks. Interesting.

It should not take too long for someone with a non-overclocked processor to run through all the finds in SGS, as a triple check. But the probability that a "prime" can be removed by such an effort, must be microscopic.

/JeppeSN

As of right now, there are 1491 SGS primes and 3176 TPS primes which do not have a T5K id.

The SGS list will continue to grow, but the TPS list won't.

The much older TPS primes which are not in T5K probably were not subject to the same rigorous validation tests. TPS was before my time here.

The much older TPS primes which are not in T5K probably were not subject to the same rigorous validation tests. TPS was before my time here.

Another future double check Michael?

The much older TPS primes which are not in T5K probably were not subject to the same rigorous validation tests. TPS was before my time here.

Another future double check Michael?

Not by us, no.

The much older TPS primes which are not in T5K probably were not subject to the same rigorous validation tests. TPS was before my time here.

Another future double check Michael?

Not by us, no.

Phew :)

SOB will keep us going for a while yet anyhow.

Day 5:


Challenge: Halloween
App: 3 (WOO-LLR)
(As of 2018-10-30 00:44:34 UTC)

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

Of those tasks that have been sent out:

1924 (13%) came back with some kind of an error. [1924 (13%) / 0 (0%) / 0 (0%)]
6556 (43%) have returned a successful result. [6556 (43%) / 0 (0%) / 0 (0%)]
6886 (45%) are still in progress. [6886 (45%) / 0 (0%) / 0 (0%)]

Of the tasks that have been returned successfully:

3093 (47%) are pending validation. [3093 (47%) / 0 (0%) / 0 (0%)]
3393 (52%) have been successfully validated. [3393 (52%) / 0 (0%) / 0 (0%)]
15 (0%) were invalid. [15 (0%) / 0 (0%) / 0 (0%)]
55 (1%) are inconclusive. [55 (1%) / 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=17756199. The leading edge was at n=17528522 at the beginning of the challenge. Since the challenge started, the leading edge has advanced 1.30% as much as it had prior to the challenge!
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

Day 5:
Since the challenge started, the leading edge has advanced 1.30% as much as it had prior to the challenge!

Day 5:
Since the challenge started, the leading edge has advanced 1.30% as much as it had prior to the challenge!

If you took, say, the week or two before the challenge began, by what percentage does the leading edge advance on a normal day?

So is multi-threading actually worth it, throughput-wise?

I tested it with the LLR program through the command prompt and in this case apparently not. Should I have turned off hyperthreading? (It's a TR 1950X)

https://i.imgur.com/NHwqb5f.jpg (EDIT: the first "h per day" should read 10.4)

I waited until the 20,000th iteration before entering the times.
____________
Long live the sievers.

+ Encyclopaedia Metallum: The Metal Archives +

Is the new Woodall badge a permanent addition or just an event treat?

So is multi-threading actually worth it, throughput-wise?

I tested it with the LLR program through the command prompt and in this case apparently not. Should I have turned off hyperthreading? (It's a TR 1950X)

https://i.imgur.com/NHwqb5f.jpg (EDIT: the first "h per day" should read 10.4)

I waited until the 20,000th iteration before entering the times.

Based on my testing primarily with Intel quad cores (excluding Broadwell, Skylake-X), I see 3 performance zones:
1, small tasks where 1 per core does not exceed L3 cache. Here it is more advantageous to run 1 per core, as multi-thread overhead can significantly reduce throughput.
2, multi-thread task(s) substantially filling L3 cache get a speedup compared to one per core, as it is no longer fighting for ram bandwidth. With sufficient ram bandwidth, this may not be seen.
3, Single or multi-thread tasks that significantly exceed L3 cache. These will be ram bandwidth limited.

Boradwell with L4 cache goes into practically unlimited ram bandwidth negating case 3. Skylake-X with its cache structure I'm less clear about. It doesn't seem to scale as well as I'd hope in practice but I don't have enough data to make any detailed observations. I suspect it may behave similarly to Zen in some respects.

Both Zen and Skylake-X are unlike traditional Intels with inclusive cache. Instead they have exclusive or non-inclusive cache respectively. Data is not duplicated in L2 and L3. I suspect there is extra data shuffling because of that, but you potentially have a bigger effective cache. I'm also unclear what happens if more than one core needs the same data.

In the case of Threadripper, we have an additional potential problem, you have two CCX per die, and two die per socket. 1 task running all core may potentially be impacted from having to cross between those barriers. 2 tasks of 8 cores each, assuming the scheduler is smart enough to put them on different dies, would be effectively like two 8 core consumer Ryzen CPUs in terms of operation and ram bandwidth (assuming all channels populated). The 1950X has a total 32MB L3 cache, so that should support 4 simultaneous Woo tasks without being limited by the ram, if at all. Based on this, I would suspect 2 or 4 tasks dividing the cores equally between them would be most efficient. That 8 is comparable, and 16 even better, I'm not sure how to explain.

One possible reason is that Ryzen family AVX units are much weaker than Intel ones, approx. half the performance. Because of that you could feed about double the Zen cores compared to Intel ones for a given number of ram channels, especially with more limited clock on higher core counts. What speed ram was the system using? If 3200 or faster, that could be fairly close to not being limited. I'm not sure this is a complete potential reason, but a starting point towards one.

One day to go!


Challenge: Halloween
App: 3 (WOO-LLR)
(As of 2018-10-31 00:35:13 UTC)

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

Of those tasks that have been sent out:

2398 (14%) came back with some kind of an error. [2398 (14%) / 0 (0%) / 0 (0%)]
8305 (48%) have returned a successful result. [8305 (48%) / 0 (0%) / 0 (0%)]
6695 (38%) are still in progress. [6695 (38%) / 0 (0%) / 0 (0%)]

Of the tasks that have been returned successfully:

3391 (41%) are pending validation. [3391 (41%) / 0 (0%) / 0 (0%)]
4824 (58%) have been successfully validated. [4824 (58%) / 0 (0%) / 0 (0%)]
24 (0%) were invalid. [24 (0%) / 0 (0%) / 0 (0%)]
66 (1%) are inconclusive. [66 (1%) / 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=17781662. The leading edge was at n=17528522 at the beginning of the challenge. Since the challenge started, the leading edge has advanced 1.44% as much as it had prior to the challenge!
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

I have good news and bad news.

The good news is we found a prime.

It's a mega prime!

It's a HUGE mega prime!

The bad news it's so huge, it's about a million digits larger than a Woodall prime would be. It's not a Woodall. :(
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

I have good news and bad news.

The good news is we found a prime.

It's a mega prime!

It's a HUGE mega prime!

The bad news it's so huge, it's about a million digits larger than a Woodall prime would be. It's not a Woodall. :(

I have good news and bad news.

The good news is we found a prime.

It's a mega prime!

It's a HUGE mega prime!

The bad news it's so huge, it's about a million digits larger than a Woodall prime would be. It's not a Woodall. :(

I have good news and bad news.

The good news is we found a prime.

It's a mega prime!

It's a HUGE mega prime!

The bad news it's so huge, it's about a million digits larger than a Woodall prime would be. It's not a Woodall. :(

The bad news it's so huge, it's about a million digits larger than a Woodall prime would be. It's not a Woodall.[/color][/b][/size] :(
Wahoooooo! EXCELLENT.

With a bit less than a day 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

With half a day to go...


Challenge: Halloween
App: 3 (WOO-LLR)
(As of 2018-10-31 12:06:03 UTC)

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

Of those tasks that have been sent out:

2541 (14%) came back with some kind of an error. [2541 (14%) / 0 (0%) / 0 (0%)]
9229 (51%) have returned a successful result. [9229 (51%) / 0 (0%) / 0 (0%)]
6381 (35%) are still in progress. [6381 (35%) / 0 (0%) / 0 (0%)]

Of the tasks that have been returned successfully:

3505 (38%) are pending validation. [3505 (38%) / 0 (0%) / 0 (0%)]
5619 (61%) have been successfully validated. [5619 (61%) / 0 (0%) / 0 (0%)]
29 (0%) were invalid. [29 (0%) / 0 (0%) / 0 (0%)]
76 (1%) are inconclusive. [76 (1%) / 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=17792006. The leading edge was at n=17528522 at the beginning of the challenge. Since the challenge started, the leading edge has advanced 1.50% as much as it had prior to the challenge!

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

Interesting statistic:

So far, 9382 challenge tasks have been successfully received back at the server. That doesn't mean all of those calculations were done correctly, but it does mean the host computer believes that the calculation was correct.

Sometimes it's not correct, especially when there's too much overclocking. With Woodall numbers, a lot of those incorrect calculations erroneously declare the number to be prime.

So far, of those 9382 returned tasks, 18 are prime.

Of those 18, 5 have been proven wrong, meaning that two other computers have run the same test resulting in a composite result with a matching residue.

8 more of the suspect primes are almost certainly wrong as well. For each, another computer has found the number to be composite. We're still waiting for a third computer to confirm that the number is composite.

For the remaining 5 potential Woodall primes, the computers for 4 of them already have a Woodall "prime" that's been proven to be wrong, and thus the computer has a history of producing faulty results. While we don't have proof yet that these particular results are wrong, we know that the computers are faulty, so it's extremely likely that these prime results are also errors.

The sole remaining potential prime also was produced by a suspect computer. It doesn't have any other proven false primes, but it does have other invalid tasks. That's essentially the same thing as a false prime -- it's a composite with the wrong residue.

All of the 18 results claiming to have found a prime are all either proven to be wrong, partially proven to be wrong, or were done on a computer with a track record of producing bad results.

And so it goes with Woodall tasks. Primes of that size are very difficult to find.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

Any chance to have the current overall standings page updated?
I know it's an external page, but last year available is 2016.

xii5ku wrote:

Oktoberfest isn't quite over yet, though:
http://www.primegrid.com/forum_thread.php?id=8194&nowrap=true#120708

That's right. The Oktoberfet's clean up is still in progress.
So these results are provisional.

I intend to update the 2018 challenge results, today, after the Halloween challenge ends.
But those results will also be provisional.

Final statistics:


Challenge: Halloween
App: 3 (WOO-LLR)
(As of 2018-11-01 00:04:53 UTC)

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

Of those tasks that have been sent out:

3097 (16%) came back with some kind of an error. [3097 (16%) / 0 (0%) / 0 (0%)]
10567 (56%) have returned a successful result. [10567 (56%) / 0 (0%) / 0 (0%)]
5138 (27%) are still in progress. [5138 (27%) / 0 (0%) / 0 (0%)]

Of the tasks that have been returned successfully:

3380 (32%) are pending validation. [3380 (32%) / 0 (0%) / 0 (0%)]
7068 (67%) have been successfully validated. [7068 (67%) / 0 (0%) / 0 (0%)]
44 (0%) were invalid. [44 (0%) / 0 (0%) / 0 (0%)]
75 (1%) are inconclusive. [75 (1%) / 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=17793704. The leading edge was at n=17528522 at the beginning of the challenge. Since the challenge started, the leading edge has advanced 1.51% as much as it had prior to the challenge!
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

Thanks everyone for a great challenge. Aggie The Pew was challenging SETI.Germany for second place right up to the end.
Miss the ghost badges already. Hopefully we see them again next Halloween.
Eudy's stats are a big improvement over my spreadsheet efforts.
Now it's time to move focus over to some GPU apps. Make sure you maintain your machines by checking the temps and blowing the dust out once in a while.
Time to get my Telescope out of storage.