Welcome to the Happy New Year Challenge!

The first Challenge of the 2018 Challenge series is a 15 day challenge to celebrate coming of the New Year! The challenge is being offered on the Seventeen or Bust LLR (SOB) application, working towards solving the Sierpinski Problem.

2018 (MMXVIII) will be a common year starting on Monday of the Gregorian calendar, the 2018th year of the Common Era (CE) and Anno Domini (AD) designations, the 18th year of the 3rd millennium, the 18th year of the 21st century, and the 9th year of the 2010s decade.

New Year's Day, also called simply New Year's or New Year, is observed on January 1, the first day of the year on the modern Gregorian calendar as well as the Julian calendar. In pre-Christian Rome under the Julian calendar, the day was dedicated to Janus, god of gateways and beginnings, for whom January is also named.

In present day, with most countries now using the Gregorian calendar as their de facto calendar, New Year's Day is probably the most celebrated public holiday, often observed with fireworks at the stroke of midnight as the new year starts in each time zone. Other global New Year's Day traditions include making New Year's resolutions and calling one's friends and family. Samoa, Tonga and Kiritimati (Christmas Island), part of Kiribati, are the first places to welcome the New Year while American Samoa and Baker Island in the United States of America are among the last.

To participate in the Challenge, please select only the Seventeen or Bust LLR (SOB) project in your PrimeGrid preferences section. The challenge will begin 1st January 2018 00:00 UTC and end 16th January 2018 00:00 UTC. Note the non-standard start time.

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 ~18 hours on fast/newer computers and 6+ 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 SOB 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> <name>llrSOB</name> <fraction_done_exact/> <max_concurrent>1</max_concurrent> </app> <app_version> <app_name>llrSOB</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 SoB 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 SoB 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 1st January 2018 00:00 UTC and received BEFORE 16th January 2018 00: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 Sierpinski Problem

Wacław Franciszek Sierpiński (14 March 1882 — 21 October 1969), a Polish mathematician, was known for outstanding contributions to set theory, number theory, theory of functions and topology. It is in number theory where we find the Sierpinski problem.

Basically, the Sierpinski problem is "What is the smallest Sierpinski number?"

First we look at Proth numbers (named after the French mathematician François Proth). A Proth number is a number of the form k*2^n+1 where k is odd, n is a positive integer, and 2^n>k.

A Sierpinski number is an odd k such that the Proth number k*2^n+1 is not prime for all n. For example, 3 is not a Sierpinski number because n=2 produces a prime number (3*2^2+1=13). In 1962, John Selfridge proved that 78,557 is a Sierpinski number...meaning he showed that for all n, 78557*2^n+1 was not prime.

Most number theorists believe that 78,557 is the smallest Sierpinski number, but it hasn't yet been proven. In order to prove it, it has to be shown that every single k less than 78,557 is not a Sierpinski number, and to do that, some n must be found that makes k*2^n+1 prime.

Seventeen or Bust

Seventeen or Bust was a distributed computing project attempting to solve the Sierpinski problem. The name of the project is due to the fact that, when founded, there were seventeen values of k < 78,557 for which no primes were known.

The project was conceived in March of 2002 by two college undergraduates. After some planning and a lot of programming, the first public client was released on April 1. Seventeen or Bust ceased operations in 2016. The project was administered by:
• Louis Helm, a computer engineer in Austin, Texas.
• David Norris, a software engineer in Urbana, Illinois.
• Michael Garrison, a Computer Science undergraduate at Eastern Michigan University in Ypsilanti, Michigan.

Starting in 2010, PrimeGrid partnered with Seventeen or Bust to work towards solving the Sierpinski Problem. After the demise of the original Seventeen or Bust project in 2016, PrimeGrid is continuing by itself to continue the Seventeen or Bust project in looking to solve the Sierpinski Problem.

As of December of 2017, PrimeGrid and Seventeen or Bust have eliminated twelve of those seventeen candidates. The project might now be styled "Five or Bust," but the original name will be kept for consistency. Current remaining k's:

21181, 22699, 24737, 55459, 67607

SOB is currently 14% of the way through a double check of old search ranges. A brief word about the SOB tasks that will be running in the challenge:

• Most of the tasks will be double checks against one or more residues from the original Seventeen or Bust project. Expect most tasks to validate almost immediately, unless your result doesn't match the residue. (Hopefully this also means a very fast clean-up!)
  
• We're currently about halfway through the n=19M range. We expect the challenge to complete the tests in the n=19M range. N=20M and n=21M are not part of the double check, so the next tasks after that are at n=22M. Expect task lengths to increase by about 20% as we move from the end of the n=19M range to the beginning of the n=22M range.
  
• Right now, SOB tasks are very slightly smaller than PSP tasks. By the end of the challenge they'll be larger; the numbers being tested will be more than half a million digits longer.
  
• We're well beyond the point where the Seventeen or Bust project thoroughly double checked their work, so finding a missed prime is a possibility. Two of their primes were found while double checking their prior work. Will we find a third?
  

Last Prime found at PrimeGrid
10223*2^31172165+1 by Szabolcs Péter (SyP) on 31 October 2016. Official Announcement.
Previous to that the last SOB candidate was eliminated in 2007.

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

As an aside, do we know how much compute time was wasted due to the two missed primes?

Planning on celebrating 2018's arrival at just the instant our challenge will be starting?

For those of you with at least one Windows computer and who won't be able to manually start everything at the beginning of the challenge, the Task Scheduler (Control Panel -> System and Security -> Administrative Tools) lets you execute programs at a specific time.

I created a task that will run 1 minute after midnight on New Year's, which executes the following commands:

I took my computer outside on this beautiful -24 C sunny day and blew out all the dust with the vaccuum cleaner. The fans are working a lot less now. It was definitely time, I had 2 spurious system lockups 2 days ago so I lightened up the computing load until I had time to clean it out.
EDIT (and also until the outdoor temperature warmed up a bit).

Oh oh another reset, this time after running a heavy load for about 18 hours since the cleanup. This isn't pretty. Maybe the same cause as before, maybe not. I was doing an SOB unit with -t 6 + PPS Sieve + a big aweful spreadsheet, but I've been doing these for a long time without a problem. This time however I had jacked up the memory speed from stock to XMP1 profile after cleaning out the system, which this RAM is supposed to handle.

The system log shows this on bootup.

... kernel: mce: [Hardware Error]: Machine check events logged
... kernel: mce: [Hardware Error]: CPU 2: Machine Check: 0 Bank 1: bf80000000000124
... kernel: mce: [Hardware Error]: TSC 0 ADDR 3b2158280 MISC 86
... kernel: mce: [Hardware Error]: PROCESSOR 0:306f2 TIME 1514710212 SOCKET 0 APIC 4 microcode 3a

Running the the stuff to the right of [Hardware Error]: through the machine check event parser:
journalctl | grep mce | sed 's/.*Hardware Error...//' | mcelog --ascii

Machine check events logged
Hardware event. This is not a software error.
CPU 2 BANK 0
TIME 1514710212 Sun Dec 31 02:50:12 2017
MCG status:
MCi status:
Machine check not valid
Corrected error
MCA: No Error
STATUS 0 MCGSTATUS 0
CPUID Vendor Intel Family 6 Model 63
(Fields were incomplete)
SOCKET 0 APIC 4 microcode 3a

Maybe a memory error, maybe cache, maybe a PCIE bus error, maybe a fluke...
I have low tolerance for hardware instability, so I'll drop the memory speed back down to vanilla.
And we'll see how that SOB unit validates.

This time however I had jacked up the memory speed from stock to XMP1 profile after cleaning out the system, which this RAM is supposed to handle.

RAM is rated at 2400 although the CPU is dogging it at 2133.
The motherboard supports DDR4 up to 3333 MHz.
The system is 2.5 years old now.

Oh oh another reset, this time after running a heavy load for about 18 hours since the cleanup. This isn't pretty. Maybe the same cause as before, maybe not. I was doing an SOB unit with -t 6 + PPS Sieve + a big aweful spreadsheet, but I've been doing these for a long time without a problem. This time however I had jacked up the memory speed from stock to XMP1 profile after cleaning out the system, which this RAM is supposed to handle.

I'd be surprised if DDR4 2400 doesn't work in most systems. Is that kit particularly aggressive in timings? Maybe more relaxed timings will help, not that you have long to diagnose it before the challenge. It may work better if you leave it on SPD and "overclock" to 2400, than use XMP profile to do same. In my testing, speed helps in this type of task far more than latency.

One other possibility, is the CPU might be close to its limit already in terms of thermal stability. Increasing the ram speed may have enabled it work a bit more, tipping it over.

I think you nailed it - the CPU is probably near the thermal limit.

It has a standard Intel CPU cooler on it, so there's no hope of O/C'ing the CPU even though I've read that the 5820K is one easily overclockable. I couldn't even raise the speed 100 MHz when it was brand new because of stability issues. I also noticed when cleaning the system yesterday that the large diameter fan on top of the case over the CPU is seized up. It's already the second one in the life of this case, now 9 years old. The power supply is a high quality 1000 W so I don't think capacitor aging is an issue.

Another factor is that it's a balmy -19 C outside, so the house tends to be warmer than summertime because the ground source heat pump is heating the house rather than cooling it.

EDIT: It's too lake to tweak the RAM timing, but I think not too lake to run out and get a new case fan.

A note about the SoB statistics page (http://www.primegrid.com/stats_sob_llr.php) as well as the SoB DC statistics I occasionally post:

Both of them define "in progress" as "the WU for that candidate has been created". It does not necessarily mean tasks from that WU have been sent out to users. Normally, there's a queue of 750 SoB tasks waiting to be sent out, so the statistics are actually 750 tasks ahead of what's actually been sent out to users.

At the start of a challenge, however, I increase the queue size so that we don't run out during the surge at the very beginning of the challenge. For this challenge, I increased the queue size from 750 to 10,000. The statistics are therefore 10,000 tasks ahead of what's actually been sent to users.

This means the statistics now show the largest "in progress" task as having n=22,530,862 whereas the largest task sent to a user is currently 19,661,623. (Remember that the double check is skipping the n=20M and n=21M ranges.)

I'll be lowering the queue size after the start.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

Go, go, GO!

Happy New Year everyone!

Over 2.6 hours has gone by and no one has turned in a result yet????
I thought some computer would be running with "-t bazillion" in app_config.xml

Wouldn't you know it, my case needs a 200 mm fan with a profile lower than 25 mm, so I came up empty--handed. My solution, for now, is to remove the defunct fan so that it doesn't impede natural airflow. And crank up the CPU fan speed to 100% in the BIOS. Speak louder, I can't hear you!

I'll be lucky to have one in at 12 hours :)

Same thing here

First results are in.

Lotsa threads. :)

EDIT: four results so far:

20 threads (i9-7940X, 13,154 sec)
20 threads (i9-7900X, 14,637 sec)
12 threads (i9-7920X, 14,870 sec)
18 threads (i9-7900X, 15,267 sec)
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

Just crashed again. Changing the memory profile from "enhanced performance" setting to "enhanced stability", leaving it at 2400 MHz for now.

Microsoft may have given you a nice New Year's Day surprise. Check if BOINC is suspended while Windows is prompting you for a reboot.

EDIT The suspension is all mine.

"Your PC will restart several times." That's Microsoft's contribution.

FFT Sizes*

SOB tasks in the challenge (so far) consist of three different FFT sizes**. The FFT size has a significant effect on both the length of each task, and the credit or challenge points awarded for each task.

1728K: n=19M, smaller k's
1920K: n=19M, larger k's and n=22M, smaller k's
2M: n=22M, larger k's

Tasks currently being sent out are in the 22M range, except for the occasional resend.

(*) While an LLR task is running, you may see the FFT being used by looking in the file called "stderr.txt" in the appropriate slot directory.

(**) Your mileage may vary. The server uses an "official" FFT size to determine credit, however, the actual FFT used on your computer may be a different size. LLR determines the optimal FFT to use depending on your CPU type, and will sometimes uses different FFT sizes on different CPUs.

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

Excellent advice, and all correct (as I found out last night when my computers didn't start up exactly as planned!) We'll need to correct the main challenge post. Thanks.

llrSOB runtimes are highly variable, hence you need to complete lots of tasks for meaningful comparisons between different configs. And you need to compute lots of tasks in parallel on different configs, because the run time of tasks will drift over time as the project proceeds through the data set.

Is there something else needed with LLR threading to stop it suspending GPU usage?

I've had very different responses to the use of the app_config.xml. It works fine on one Linux box, suspends the GPU on a second Linux box, and just leaves GPU units waiting on a Win10 box.

Microsoft may have given you a nice New Year's Day surprise. Check if BOINC is suspended while Windows is prompting you for a reboot.

EDIT The suspension is all mine.

"Your PC will restart several times." That's Microsoft's contribution.

I don't believe that's microsoft's contribution, i have no surprises and my 3 old computers are running on windows 7 all the time.

Is there any way, or would it be too hard to do.
What I am thinking is maybe a TEST task, one that can be ran over and over again to test system tweaks. Maybe half the size, (don't need to test for 20 hours) so we can really get our systems running the best we can.
This way we know it is X long, no worries about is this a long or short task
The test task could be downloaded, we test with it all we want and it never gets sent back to the PG server.
Call it a test task or a testing program.

Just a thought.

Happy new year everyone!

I can think of some not ideal ways to test this.

1, you can't run a "smaller" task as it will load the system differently. It has to be representative of current work sizes. To reduce time, maybe someone could crunch one to say 95% done, then you finish it. Subtract the time and what's left is what your system took.
2, manually run LLR with a specified task, and look at how the runtime progresses. It has been a long time since I ran this, so I'm not sure what potentially useful output there might be.
3, use Prime95 benchmark mode. 29.x has a new screen which makes running it a lot easier, no config file editing needed any more. Prime95 shares the same code as LLR so this will be a close indication. This will be ok for testing how hardware affects it (CPU clock, ram speed/timings, how many threads are run). Result will take a bit of work to translate to estimated unit time. There is a small potential difference in FFT types I don't understand, but if run on same system they should be consistent within that context at least. Faster is faster, if not absolutely representative.

As much as Michael warns against it, I find using live work "good enough" for general indication. There is task to task variation, especially if the system is doing other things. The only thing I take care on is to only compare same size FFTs, as that makes a relatively big difference, which means manually looking at each individual result. Also it helps to average a big sample. One unit will be risky, if you're averaging 20+, especially if there is low variation between them, it'll probably be ok.

After 1 day...

Challenge: Happy New Year
App: 13 (SoB-LLR)
(As of 2018-01-02 00:46:59 UTC)

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

Of those tasks that have been sent out:

874 (11%) came back with some kind of an error. [874 (11%) / 0 (0%) / 0 (0%)]
454 (6%) have returned a successful result. [454 (6%) / 0 (0%) / 0 (0%)]
6552 (83%) are still in progress. [6552 (83%) / 0 (0%) / 0 (0%)]

Of the tasks that have been returned successfully:

0 (0%) are pending validation. [0 (0%) / 0 (0%) / 0 (0%)]
422 (93%) have been successfully validated. [422 (93%) / 0 (0%) / 0 (0%)]
0 (0%) were invalid. [0 (0%) / 0 (0%) / 0 (0%)]
32 (7%) are inconclusive. [32 (7%) / 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=22287910. The leading edge was at n=19690628 at the beginning of the challenge. Since the challenge started, the leading edge has advanced 13.19% as much as it had prior to the challenge!


Normal SoB crunching is about 230 per day. Over 30 times as many tasks were sent out in the first day. I think it's going to be a very interesting challenge.

Will we find a missed prime?
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

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

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

For anyone that is curious, this is slightly misleading since n=20M and n=21M were not part of the double check.

It is interesting, is this OK if after one day of a challenge

454 (6%) have returned a successful result.

I thought that each SoB task should took several days rather than one day.

It is interesting, is this OK if after one day of a challenge

454 (6%) have returned a successful result.

I thought that each SoB task should took several days rather than one day.

Stats at about a day and a half:


Challenge: Happy New Year
App: 13 (SoB-LLR)
(As of 2018-01-02 15:34:46 UTC)

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

Of those tasks that have been sent out:

1121 (13%) came back with some kind of an error. [1121 (13%) / 0 (0%) / 0 (0%)]
1033 (12%) have returned a successful result. [1033 (12%) / 0 (0%) / 0 (0%)]
6802 (76%) are still in progress. [6802 (76%) / 0 (0%) / 0 (0%)]

Of the tasks that have been returned successfully:

0 (0%) are pending validation. [0 (0%) / 0 (0%) / 0 (0%)]
961 (93%) have been successfully validated. [961 (93%) / 0 (0%) / 0 (0%)]
2 (0%) were invalid. [2 (0%) / 0 (0%) / 0 (0%)]
70 (7%) are inconclusive. [70 (7%) / 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=22350103. The leading edge was at n=19690628 at the beginning of the challenge.


A question that comes up during double checks from time to time is "how many of the original residues were bad?" This isn't a comprehensive answer, but of the residues currently in the live database that have been tested:

Correct residues: 8739
Incorrect residues: 334 (3.7%)

Those numbers exclude residues in work units that have already been purged from the database, so those numbers represent tests from the last month or so.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

We're now processing the n=22M tasks, so processing times are longer, the numbers being checked are over 6 million digits long, and credit per task for the latest numbers is over 31 thousand.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

After two days...


Challenge: Happy New Year
App: 13 (SoB-LLR)
(As of 2018-01-03 00:23:54 UTC)

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

Of those tasks that have been sent out:

1198 (12%) came back with some kind of an error. [1198 (12%) / 0 (0%) / 0 (0%)]
1407 (15%) have returned a successful result. [1407 (15%) / 0 (0%) / 0 (0%)]
7003 (73%) are still in progress. [7003 (73%) / 0 (0%) / 0 (0%)]

Of the tasks that have been returned successfully:

0 (0%) are pending validation. [0 (0%) / 0 (0%) / 0 (0%)]
1321 (94%) have been successfully validated. [1321 (94%) / 0 (0%) / 0 (0%)]
5 (0%) were invalid. [5 (0%) / 0 (0%) / 0 (0%)]
81 (6%) are inconclusive. [81 (6%) / 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=22401334. The leading edge was at n=19690628 at the beginning of the challenge.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

Hi,

I've finished a couple of tasks but i'm not showing up in the ranking list.

Is something wrong?

Scoring Information

Scores will be kept for individuals and teams. Only tasks issued AFTER 1st January 2018 00:00 UTC and received BEFORE 16th January 2018 00: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.

After 2.5 days:


Challenge: Happy New Year
App: 13 (SoB-LLR)
(As of 2018-01-03 12:44:22 UTC)

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

Of those tasks that have been sent out:

1305 (13%) came back with some kind of an error. [1305 (13%) / 0 (0%) / 0 (0%)]
1993 (19%) have returned a successful result. [1993 (19%) / 0 (0%) / 0 (0%)]
7019 (68%) are still in progress. [7019 (68%) / 0 (0%) / 0 (0%)]

Of the tasks that have been returned successfully:

0 (0%) are pending validation. [0 (0%) / 0 (0%) / 0 (0%)]
1884 (95%) have been successfully validated. [1884 (95%) / 0 (0%) / 0 (0%)]
8 (0%) were invalid. [8 (0%) / 0 (0%) / 0 (0%)]
101 (5%) are inconclusive. [101 (5%) / 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=22450186. The leading edge was at n=19690628 at the beginning of the challenge.


I'm doing something a little different. Those 8 invalid tasks are the result of computation errors (hardware errors). It's usually the result of too much overclocking, although there are other causes. I've sent PMs to the people who own those computers to let them know there's something wrong. Often the fix is as easy as backing off on the overclocking. I may not keep this up for the whole challenge; it depends on how many there are. Of course, it's not necessary for me to tell anyone -- if you ever see any "invalid" tasks, something is wrong and needs to be looked at. But for now, I'm trying to make sure everyone knows. So far, every one of those computers is in one of the top 6 teams, so whether the problem is corrected or not could affect the team standings at the top of the leaderboards.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

It took just under 3 days for all of the 10,000 extra tasks I loaded for the challenge to be sent out. The server is now generating new work to replace each task as it's sent out, i.e., things are back to normal.

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

Three days, one-fifth, of the challenge is complete!


Challenge: Happy New Year
App: 13 (SoB-LLR)
(As of 2018-01-04 00:01:49 UTC)

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

Of those tasks that have been sent out:

1493 (14%) came back with some kind of an error. [1493 (14%) / 0 (0%) / 0 (0%)]
2521 (23%) have returned a successful result. [2521 (23%) / 0 (0%) / 0 (0%)]
7030 (64%) are still in progress. [7030 (64%) / 0 (0%) / 0 (0%)]

Of the tasks that have been returned successfully:

1 (0%) are pending validation. [1 (0%) / 0 (0%) / 0 (0%)]
2394 (95%) have been successfully validated. [2394 (95%) / 0 (0%) / 0 (0%)]
9 (0%) were invalid. [9 (0%) / 0 (0%) / 0 (0%)]
117 (5%) are inconclusive. [117 (5%) / 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=22491127. The leading edge was at n=19690628 at the beginning of the challenge.


The team battle is very close, with the top for teams separated by 1.4M, 1.5M, and 0.6M points. The individual standings are also very close, with the top 4 separated by 200K, 470K, and 220K. Both teams and individuals have swapped places several times as their computers, running at vastly different speeds, return small groups of tasks quickly, or large groups of tasks slowly.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

Thanks to this challenge, the SOB double check is now 16% complete. When the challenge started, the double check was about 14% complete.


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

After 4 days...


Challenge: Happy New Year
App: 13 (SoB-LLR)
(As of 2018-01-05 00:21:10 UTC)

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

Of those tasks that have been sent out:

1910 (15%) came back with some kind of an error. [1910 (15%) / 0 (0%) / 0 (0%)]
3763 (29%) have returned a successful result. [3763 (29%) / 0 (0%) / 0 (0%)]
7328 (56%) are still in progress. [7328 (56%) / 0 (0%) / 0 (0%)]

Of the tasks that have been returned successfully:

0 (0%) are pending validation. [0 (0%) / 0 (0%) / 0 (0%)]
3593 (95%) have been successfully validated. [3593 (95%) / 0 (0%) / 0 (0%)]
20 (1%) were invalid. [20 (1%) / 0 (0%) / 0 (0%)]
150 (4%) are inconclusive. [150 (4%) / 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=22620046. The leading edge was at n=19690628 at the beginning of the challenge.


The double check is 16.27% complete.

Still no missing primes, but we will keep looking.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

What score would a missed prime garner during Tour de Primes next month?
Assume it will be found between 22% and 37% of the double-check.

What score would a missed prime garner during Tour de Primes next month?
Assume it will be found between 22% and 37% of the double-check.

What score would a missed prime garner during Tour de Primes next month?
Assume it will be found between 22% and 37% of the double-check.

That's probably between 7 and 8 million digits. The formula is here.

One third of the challenge is complete!


Challenge: Happy New Year
App: 13 (SoB-LLR)
(As of 2018-01-06 00:23:37 UTC)

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

Of those tasks that have been sent out:

2667 (17%) came back with some kind of an error. [2667 (17%) / 0 (0%) / 0 (0%)]
5013 (33%) have returned a successful result. [5013 (33%) / 0 (0%) / 0 (0%)]
7622 (50%) are still in progress. [7622 (50%) / 0 (0%) / 0 (0%)]

Of the tasks that have been returned successfully:

2 (0%) are pending validation. [2 (0%) / 0 (0%) / 0 (0%)]
4807 (96%) have been successfully validated. [4807 (96%) / 0 (0%) / 0 (0%)]
31 (1%) were invalid. [31 (1%) / 0 (0%) / 0 (0%)]
173 (3%) are inconclusive. [173 (3%) / 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=22755404. The leading edge was at n=19690628 at the beginning of the challenge.


The double check is now 16.88% complete.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

Five and a half days...


Challenge: Happy New Year
App: 13 (SoB-LLR)
(As of 2018-01-06 12:04:16 UTC)

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

Of those tasks that have been sent out:

3111 (18%) came back with some kind of an error. [3111 (18%) / 0 (0%) / 0 (0%)]
5660 (33%) have returned a successful result. [5660 (33%) / 0 (0%) / 0 (0%)]
8179 (48%) are still in progress. [8179 (48%) / 0 (0%) / 0 (0%)]

Of the tasks that have been returned successfully:

0 (0%) are pending validation. [0 (0%) / 0 (0%) / 0 (0%)]
5434 (96%) have been successfully validated. [5434 (96%) / 0 (0%) / 0 (0%)]
39 (1%) were invalid. [39 (1%) / 0 (0%) / 0 (0%)]
187 (3%) are inconclusive. [187 (3%) / 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=22862651. The leading edge was at n=19690628 at the beginning of the challenge.


The double check is now 17.21% completed!
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

Right now, the Czech National Team has about a 500K point lead over SETI.Germany in a very close race for third place.

Tasks currently vary in credit from about 20K to 30K, with more recent tasks at the higher end of that range. They'll certainly go up some more before we're done.

So far, 14 CNT tasks have been found to be invalid (approximately 280K to 420K points), while 3 SG tasks are invalid so far (60K to 90K points). "Invalid" means there was a hardware calculation error. The computer malfunctioned. This is not supposed to happen if the computer is working correctly.

In a race this close, those invalid tasks could make the difference.

I've heard back from a few people who have had invalid tasks. Typically the most common cause is too much overclocking, and, sure enough, that was the cause for a few of these as well.

One other cause was heat. For those of you who are struggling with high CPU temperatures, I recommend a program called TThrottle. Not only does it monitor your CPU temperatures, but it will slow down BOINC tasks just enough to keep CPU temperatures below whatever value you specify. It integrates very nicely with BOINC Tasks since both have the same author. This is a Windows program. https://efmer.com/tthrottle/

I've found that setting the temperature limit too low really slows down BOINC because the temperature is too low for the CPU fan to spin up. 75C seems to be a good compromise between keeping the CPU cool yet warm enough for the fans to provide a lot of cooling. I have one computer, an old laptop, with a real temperature problem, and TThrottle keeps the CPU safe while running the BOINC tasks at about 50% speed. On the other computers, it's essentially a safeguard against the computer overheating, and it takes effect about 15-25 degrees before the BIOS would act.

Another cause I'm hearing is "I think it's because Windows 10 rebooted." Yeah. 'Nuf said.

Good luck everyone!
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

+1 on TThrottle.

I've used it for many years and is an excellent program. It has saved my hardware's ass many times such as when a fan (CPU + GPU) dies while crunching, or an initial fan curve is set wrong by accident, etc.

I think most Windows users (if not all) should use it. I also recommend BOINC Tasks as well by the same author. There's a Linux version of that.

Link to TThrottle's manual to learn more: https://efmer.com/tthrottle-manual/

Homepage: https://efmer.com/


____________
Largest Primes to Date:
As Double Checker: SR5 109208*5^1816285+1 Dgts-1,269,534
As Initial Finder: SR5 243944*5^1258576-1 Dgts-879,713

I have also noticed that disabling the WU service doesn't seem 100% effective any more. I've had reboots when I thought I had it disabled too. I've now taken to blocking WU at network level and that seems to have stopped it. That should be ok until MS starts using alternate servers...

After 6 days:


Challenge: Happy New Year
App: 13 (SoB-LLR)
(As of 2018-01-07 00:00:26 UTC)

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

Of those tasks that have been sent out:

3369 (19%) came back with some kind of an error. [3369 (19%) / 0 (0%) / 0 (0%)]
6280 (35%) have returned a successful result. [6280 (35%) / 0 (0%) / 0 (0%)]
8295 (46%) are still in progress. [8295 (46%) / 0 (0%) / 0 (0%)]

Of the tasks that have been returned successfully:

0 (0%) are pending validation. [0 (0%) / 0 (0%) / 0 (0%)]
6046 (96%) have been successfully validated. [6046 (96%) / 0 (0%) / 0 (0%)]
45 (1%) were invalid. [45 (1%) / 0 (0%) / 0 (0%)]
189 (3%) are inconclusive. [189 (3%) / 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=22922074. The leading edge was at n=19690628 at the beginning of the challenge.


The double check is 17.52% complete.


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

189 (3%) are inconclusive. [189 (3%) / 0 (0%) / 0 (0%)]

Well .. one of my inconclusives is now valid. I believe this means that I and my DC proved an invalid residual from 17oB?

6.5 days...


Challenge: Happy New Year
App: 13 (SoB-LLR)
(As of 2018-01-07 12:32:41 UTC)

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

Of those tasks that have been sent out:

3837 (20%) came back with some kind of an error. [3837 (20%) / 0 (0%) / 0 (0%)]
6947 (36%) have returned a successful result. [6947 (36%) / 0 (0%) / 0 (0%)]
8589 (44%) are still in progress. [8589 (44%) / 0 (0%) / 0 (0%)]

Of the tasks that have been returned successfully:

0 (0%) are pending validation. [0 (0%) / 0 (0%) / 0 (0%)]
6696 (96%) have been successfully validated. [6696 (96%) / 0 (0%) / 0 (0%)]
49 (1%) were invalid. [49 (1%) / 0 (0%) / 0 (0%)]
202 (3%) are inconclusive. [202 (3%) / 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=23004884. The leading edge was at n=19690628 at the beginning of the challenge.


We've sent out all of the n=22M numbers and have started on the n=23M range.

The double check is 17.85% complete.

We're still looking for that elusive missed prime!
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

We're at the halfway point of the challenge!


Challenge: Happy New Year
App: 13 (SoB-LLR)
(As of 2018-01-08 12:08:19 UTC)

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

Of those tasks that have been sent out:

4542 (21%) came back with some kind of an error. [4542 (21%) / 0 (0%) / 0 (0%)]
8261 (39%) have returned a successful result. [8261 (39%) / 0 (0%) / 0 (0%)]
8570 (40%) are still in progress. [8570 (40%) / 0 (0%) / 0 (0%)]

Of the tasks that have been returned successfully:

0 (0%) are pending validation. [0 (0%) / 0 (0%) / 0 (0%)]
7956 (96%) have been successfully validated. [7956 (96%) / 0 (0%) / 0 (0%)]
66 (1%) were invalid. [66 (1%) / 0 (0%) / 0 (0%)]
239 (3%) are inconclusive. [239 (3%) / 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=23120167. The leading edge was at n=19690628 at the beginning of the challenge.


The double check is 18.50% complete. When the challenge started we were less than 15% complete.

The numbers being tested now are just below 7 million digits.


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