All of the SoB DC candidates have been loaded into the system. Once the existing leading edge tasks are all sent out the server will start sending out the smaller double check tasks. It will probably be another two or three days until the double check tasks start going out. There will also be occasional resends of leading edge tasks until they're all completed. If the past is any indication, it will take about 6 months for all of the leading edge workunits complete. Until then, there will be a possibility of getting one of the long SoB tasks, although the probability of that happening will grow decreasingly small with time.

The double check will start at n=7M. Everything below that has already been fully double checked. It will end just below n=31M. I expect the double check to take several years.

As far as deadlines go, we will start with the same deadlines we used for the PSP double check:

Deadlines

The new short double check tasks will start with a deadline of 4 days.

When n reaches 8,000,000, I will change the deadline to 6 days.

When n reaches 10,000,000, I will change the deadline to 10 days.

When n reaches 13,000,000, I will change the deadline to 14 days.

When n reaches 16,000,000, I will change the deadline back to 21 days.

As an aside, if for some reason you want to run the longer leading edge SoB tasks, there's still about 200 left. After those are gone, there probably won't be any more until sometime in the 2020s.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

As a very rough estimate, I think it would start off slightly smaller than TRP and grow from there.

Just started on my TRP phase so will give SoB a few days to avoid some leading edge then be full-bore double-check. Is the April challenge likely to be SoB therefore?

Just started on my TRP phase so will give SoB a few days to avoid some leading edge then be full-bore double-check. Is the April challenge likely to be SoB therefore?

We haven't discussed challenges yet.

The first of the double check tasks have been generated, although none have been sent out yet. There's still 91 "big" tasks in the queue, and that's more than a day's worth.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

Might be a dumb question, and it's not very important to me but are the "big" tasks going to receive the old level of credit or will it be the adjusted credit for new shorter tasks? I'm curious as the SOB I have running should finish around the 31st after when short tasks will start being sent out (29 days 17 hours and 30 minutes crunching so far).

None of the double check tasks have gone out yet, but when they do, don't be surprised if you see something different than what you're used to.

Many of these candidates have multiple -- and different -- pre-existing residues associated with them. We don't know which, if any, of these residues is correct. So they *all* get loaded into the system as "validated but inconclusive" results. Don't be surprised if you get workunits that have two or three "fake" results. It's normal.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

Double check tasks have started being sent out.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

No NEW tasks will be sent out, but I'm guessing it will still be possible to get large units from timed out, aborted or inconclusive work for a while yet.

So am I right that tasks above 32M will not be sent out till the end of this Double Check?

I've expanded the queue size to its normal operating size, and since there's very few total tests at the lower n values, that was enough to push n above 10M.

As per the plan, the deadline has therefore been increased to 10 days. At n=13M the deadline will go to 14 days. That won't take very long because there's less than 4000 tasks, total, between n=10M and n=13M.

The first range where there's a lot of tasks is n=14M.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

I've put together progress tables that match the tables I'm using for the PSP double check:

EDIT: This table is now grouped by "n" (in millions), rather than by FFT size.

What are the bookmakers' odds we will find anything during this double check? I mean, what are the chances there exists one or more k (out of the five relevant ones) such that a prime k*2^n+1 exists for some n between 7 million and 31 million? Anyone wants to make a bet? /JeppeSN

On the other hand, it also means we've wasted countless thousands of hours of computing in that K that was completely unnecessary and could have been avoided had the search been managed differently.

I can't remember if it was economics, game theory, or something else, but there is a guideline that basically says don't let past events lead you into making a bad decision for the future. We can't change the past, so what is the most optimal solution for the future? I'd say at this point, finding a prime in double check is preferable to resuming at leading edge.

Of course. The past is immutable. We can only change the future. Hopefully we learn from the past to make a better tomorrow.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

...
On the other hand, it's not clear whether SoB's double check compared residues. They may have simply run everything twice. If that's what they did, then it's entirely possible for there to have been two faulty calculations on the same number. It doesn't happen often, but it does happen. So it's still possible that there's missed primes at lower n values as well.
...

If I understand that http://www.primegrid.com/workunit.php?wuid=519659035 right, it should confirm the assumption that SoB did not compare residues.
We see 3 imported results and obviously, none of them was correct.

Anything misunderstood on my side, or is it really like that....?

...
On the other hand, it's not clear whether SoB's double check compared residues. They may have simply run everything twice. If that's what they did, then it's entirely possible for there to have been two faulty calculations on the same number. It doesn't happen often, but it does happen. So it's still possible that there's missed primes at lower n values as well.
...

If I understand that http://www.primegrid.com/workunit.php?wuid=519659035 right, it should confirm the assumption that SoB did not compare residues.
We see 3 imported results and obviously, none of them was correct.

Anything misunderstood on my side, or is it really like that....?
If so, strange, at least.

Just a question: if someone finds a prime, who is the discoverer? Do you know the name of crunchers from the Seventeen or Bust project?

For a workunit:

Case A: all the results from the Seventeen or Bust project are invalid. The first that completes the test here at PrimeGrid is the discoverer.
Case B: there are two (or more) inconclusive validations from the Seventeen or Bust project, but one of them is correctly doublechecked by a PrimeGrid cruncher. Discoverer is...?
Case C: ...

Just a question: if someone finds a prime, who is the discoverer? Do you know the name of crunchers from the Seventeen or Bust project?

For a workunit:

Case A: all the results from the Seventeen or Bust project are invalid. The first that completes the test here at PrimeGrid is the discoverer.
Case B: there are two (or more) inconclusive validations from the Seventeen or Bust project, but one of them is correctly doublechecked by a PrimeGrid cruncher. Discoverer is...?
Case C: ...

So if we complete those 150000 tasks we can consider that all Units of Work below 32M was tested at least twice and it is provable that there is no lost primes below 32M ?

Except we arent doublechecking the k of the most recently found Prime.

I still have some SoB 7.06 units running on some computers and I saw SoB 8.0 coming in.
I'm just curious what the difference is? Is the new version more stable?
Should I abort 7.06 units that have not yet run for very long?

I still have some SoB 7.06 units running on some computers and I saw SoB 8.0 coming in.
I'm just curious what the difference is? Is the new version more stable?
Should I abort 7.06 units that have not yet run for very long?

I've updated the plan for increasing task deadlines as the double check progresses. The deadline is currently at 10 days. The full plan is as follows:

Deadlines

As per the plan, n has hit 13 million and I've increased the deadline to 14 days.


Deadlines

Well, this one is weird. I've swiped through logs -- nonthing suspicious.

Whynot,

Something bizarre occurred on your computer, and we can not figure out from our end what may have happened. You were definitely sent v8.00 of the software, but if your logs show that you executed v7.06 we have no explanation. The one thing that is certain is that 7.06 is incapable of running those tasks.

My only advice to you is to completely wipe your BOINC installation and reinstall. Beyond that, we are not going to be able to help you further with this problem. Good luck.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

JimB wrote:

Edit: Actually, your result makes no sense whatsoever. The system says it gave you a v8.00 job but when you look at the stderr output it's the wrong wrapper (7.05 instead of 8.00) and the wrong version of LLR (3.8.17 instead of 3.8.20). WTF?

Excuse me, sir, I beg to differ. While it's not 8.00, it's 7.06 (also that explains llr_3.8.17):

08-Apr-2017 07:30:55 [PrimeGrid] [slot] linked ../../projects/www.primegrid.com/primegrid_llr_wrapper_7.06_x86_64-pc-linux-gnu to slots/0/primegrid_llr_wrapper_7.06_x86_64-pc-linux-gnu

(lucky me, I have slot-debug enabled). Still, I see 7.05 laying in /projects/ ; its utime is 2016Apr4, should I get rid of it? Also, I see that 7.06 is still in use, so I won't go reset right now.

<core_client_version>6.10.58</core_client_version>
<![CDATA[
<stderr_txt>
BOINC llr wrapper (version 7.05)
Using Jean Penne's llr (64 bit)
LLR Program - Version 3.8.17, using Gwnum Library Version 28.8
07:30:56 (2410): called boinc_finish

</stderr_txt>
]]>

We have reached the 1% complete mark!

Are their still many leading edge candidates out there in progress from prior to beginning the double check? Are we close to 100% double checking now?

Thanks,
Jay

We have now completed 2 percent of the double check. The number of older leading edge tasks still in progress has dropped to 416; it was over 2000 at the beginning of the double check.

The double check is now 3% complete. Only 231 full-sized leading edge tasks are still in progress.

Not sure if this is where this should go but averaging roughly 2 days per WU. I6700K with hyperthreading. Thought someone might find that useful. I am really new to SOB and PrimeGrid though so may be doing it all wrong.

Something else you can try is Process Lasso (https://bitsum.com/?inproduct) or similar where you can permanently set the affinity to each app. Set all LLR sub projects (all run the same app) to run only on physical cores 0,2,4,6 (similar to turning HT off but only for that app. Do the same for GFN CPU apps. Yes there are a few slightly different ones). Leave the sieve app on 0-7 cores. And set the GPU apps on 1,3,5,7 when running LLR or GFN CPU or 0-7 if only running sieves. This works the best for me without turning HT off (and back on for sieves) and slightly better performance than the setting of 'use 50% of processors' which still uses all threads leaving HT confliction going on. It only limits total throughput to 50% and not limit to only physical cores which you want for LLR CPU and GFN CPU apps
____________
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

The SoB double check is now 4% completed. 97 full size leading edge tasks are still out in the field being processed.

The double check is approaching n=16M. At approximately n=16M I will increase the deadline from 14 days to 21 days, as previously announced.

As per the plan, now that n is above 16 million, I have increased the deadline to 21 days.


Deadlines

5% of the double check is now complete. We're approximately 4 months in, and at this rate the double check will take between 6 and 7 years to complete.

Also, 48 leading edge tasks from workunits started before the double check are still in progress.

5% of the double check is now complete. We're approximately 4 months in, and at this rate the double check will take between 6 and 7 years to complete.

Maybe a challenge or two before the tasks get too large again to create some boosts in speed?
How long has it been since a SOB challenge? Seems like now would be the time.

I looked at the Challenge Series page. Looks like no dedicated SOB challenges since 2008. One in early 2015 that was a three project LLR challenge that had some SOB.

(July 24)

Also, 48 leading edge tasks from workunits started before the double check are still in progress.

I see on the SOB stats page that two multipliers (values of k) have finished all their old leading edge tasks, namely 21181 and 67607. /JeppeSN

The last of the leading edge candidates has finished. All ks on the SoB status page now show DC candidates in the the "max in progress" column. I.e., "max in progress" is now in the 16 million range.

There's a handful of straggling, superfluous leading edge tasks still running out there, but their results aren't needed and once they finish, successful or not, no new tasks will be sent out in those workunits. From this point on any SoB tasks that are sent out are guaranteed to be the shorter DC tasks.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

The double check is now 6% complete. Candidates are just under 5 million digits in length.

All of the large, leading edge candidates that were still being tested when the double check began have been validated, so there's no chance of a leading edge prime until after the double check is completed. Of course, it's possible we'll find a missed prime during the double check, which is why we're doing this. Although all the leading edge candidates have been validated, there's still 11 redundant/unnecessary leading edge tasks still in progress, approximately 5 months after the double check began.

We're now checking candidates 5 million digits long!

The double check is now 7% complete.

Candidates are over five million digits in length.

We have passed n=17 million! The double check is now 7.3% complete.

If you're wondering why the double check completely skipped the range from n=17.0 million to n=17.2 million, that's because 17.0 to 17.2 is the first range that PrimeGrid processed when we started collaborating with Seventeen Or Bust. Since it was done here and already fully double checked, there's nothing further to check in that range. Once all the in-progress tasks are completed, we will have completely double checked all the work Seventeen Or Bust did prior to PrimeGrid's involvement in the search.

Similarly, we'll also be skipping 18.0 to 18.5, 20.0 to 22.0, and 27.0 to 28.0 because those are also ranges that were done at PrimeGrid.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

So I've got a task with an inconclusive result comparing only the imported residue. Would you say that an inconclusive result is "necessary, but not sufficient" for finding a prime in the DC?

NB. all my other SoB DC tasks (24 of them) have had good results, so the chance of a bad result from this computer is fairly low. How many imported residues so far have been shown to be incorrect?

How many imported residues so far have been shown to be incorrect?

So I've got a task with an inconclusive result comparing only the imported residue. Would you say that an inconclusive result is "necessary, but not sufficient" for finding a prime in the DC?

A significant number of the imported residues have been wrong. I've hit quite a few myself. Here's one of them.

Of the imported results currently in the system:
2187 are waiting for a user to finish
3943 are valid
170 are invalid
40 are inconclusive

Of the total completed so far, the fraction of imported residues which are invalid or inconclusive =~ 5%.

If this average rate holds, we should expect to see first-pass double-check tasks not matching the imported residues approximately once for every 20 candidates double-checked.

A significant number of the imported residues have been wrong. I've hit quite a few myself.

I've gotten a couple inconclusive ones too, and I haven't even processed that many tasks.

Right. If it's a calculation error in the original task, then it's good we're double checking! Based on the previous discussion, though, it seems like most inconclusive results are due to incompatible software?

Thanks for explaining! Another stupid question -- what measures are you taking to backup the current results? I'd hate to see the new results lost in the (unlikely) case of a server failure.