Tentatively, on March 10th we will start an SoB challenge with the purpose of giving a big boost to the SoB double check. This of course assumes that the SoB-DC has begun before then. We therefore have about 6 weeks to start the double check. Or we could rearrange the challenge schedule, but I expect to be able to start the double check before then.

For those of you who are familiar with the PSP double check, this will be similar, with two significant differences:

1) The SoB double check is much, much larger. It will take years to complete. The numbers being tested are much larger, and unlike PSP, a significant portion of the largest numbers need to be double checked. The original PSP project died a few years ago, so all the largest PSP numbers were all crunched at PrimeGrid and don't need to be checked further. About 50% of all the SoB candidates, which includes the largest most recent numbers, need to be double checked.

2) The residues produced in the SoB project are not compatible with the LLR app that we use at PrimeGrid. This means we can't compare our tests to their tests. However, we can make LLR run in a mode that's compatible with their tests. That's the good news. The bad news is that this is about 50% slower than a normal LLR test. Because of this, we won't save as much time when using SoB's residues as we normally would, but it's better than nothing.

As with the PSP double check, we will continue using the credit bonus for long tasks, even though initially the tasks will be shorter. Also, I anticipate that the credit for tasks using the slower SoB algorithm will be adjusted to compensate for the longer run times.

That's pretty much all the information I have at this time. We're still working on getting everything ready, and there's several major decisions that we've yet to make. Feel free to ask questions, but there's a good chance I won't have answers until later.

P.S.: There's also a third difference: Two of SoB's primes were actually found while they were doing their own double checks of early work. It's impossible to say if this was just luck or whether there was a reason those two primes were missed. It's possible there may be more missed primes.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

Do we know if they were matching residues, or just running candidates a second time for the old double check?

What % of the total work is n < the highest prime found in the old double check?

If we know they were getting matched residues during their own double check, and it's a month or more of crunching to get to the highest prime found in the double check, then does it make sense to start the double check there?

However, we can make LLR run in a mode that's compatible with their tests. That's the good news. The bad news is that this is about 50% slower than a normal LLR test. Because of this, we won't save as much time when using SoB's residues as we normally would, but it's better than nothing.

Running two "standard" LLR test would give about the same performance comparing to run only single "slower/compatible" one (and compare old residues).
Assuming there is no [significant] performance benefit, we get extra information about residue reliability that we may investigate further.
Correct?

I think I was misreading it like Honza, where "50% slower" implied takes twice the time, as opposed to "takes 50% longer" which seems to be the case.

2) The residues produced in the SoB project are not compatible with the LLR app that we use at PrimeGrid. This means we can't compare our tests to their tests. However, we can make LLR run in a mode that's compatible with their tests. That's the good news. The bad news is that this is about 50% slower than a normal LLR test. Because of this, we won't save as much time when using SoB's residues as we normally would, but it's better than nothing

For each of the five remaining k multipliers, will the double check restart from exponent n=1?

/JeppeSN

2) The residues produced in the SoB project are not compatible with the LLR app that we use at PrimeGrid. This means we can't compare our tests to their tests. However, we can make LLR run in a mode that's compatible with their tests. That's the good news. The bad news is that this is about 50% slower than a normal LLR test. Because of this, we won't save as much time when using SoB's residues as we normally would, but it's better than nothing

This makes no sense. LLR & SoB client both use GW library. LLR uses a proth test, while SOB client does a base-3 (?) PRP test. The difference between these two is one extra squaring (a few milliseconds). I don't understand why LLR should be 50% slower in this "compatibility" mode.

If that is truly the case, please ask Jean to put in an actual compatibility mode that takes the same time.

EDIT:- Ok, I just checked it for myself with the Force PRP option. You're right, it is appr. 50% slower.

I don't know why it is happening, but I would classify this as a _bug_ in LLR. Please report this to Jean Penne so that he can fix this.

I don't know why it is happening, but I would classify this as a _bug_ in LLR. Please report this to Jean Penne so that he can fix this.

is the Sob double check likely to start before the end of February?

No problem -- just trying to figure out my strategy for the Tour de Primes.

If you were to find a prime during double checking of Seventeen-or-Bust, since the Top 5000 requires more than 1'290'000 bits for a prime to be huge enough, the exponent n of the prime k*2^n + 1 would have to be n > 1.29M.

/JeppeSN

No problem -- just trying to figure out my strategy for the Tour de Primes.

If you were to find a prime during double checking of Seventeen-or-Bust, since the Top 5000 requires more than 1'290'000 bits for a prime to be huge enough, the exponent n of the prime k*2^n + 1 would have to be n > 1.29M.

/JeppeSN

Even if we start the DC with n below 1.29M, it will grow beyond that almost immediately. There's a grand total of 41 candidates below n=1.29M. All of those have SoB residues to validate against, so it's a total of 41 very short tasks.

Regardless of whether it makes the T5K list or not, it would be totally awesome to eliminate a K with such a small number.

If I'm not mistaken, the old SoB project found primes in double check. GIMPS have found primes in double check. I found a prime in double check in the former rieselsieve project. It is certainly not impossible, especially for projects that have run separate first pass and double check efforts.

My expectation is that at most 5 primes will be found by the SoB DC.

GIMPS have found primes in double check.

(Barring the unlikely event that two primes are found in the same K before we can shut off the work generator.)

(Then both would be winners in a sense. The smaller one would be more interesting, as the first example for that K. But the larger one would clearly get more credit points and a higher position on Top 5000.)

When we found the recent SoB prime, did we let the remaining smaller work units on the same K value finish?

/JeppeSN

When we found the recent SoB prime, did we let the remaining smaller work units on the same K value finish?

Will that mean that for K=10223, every N below 31172165 will eventually be checked, once those twenty outstanding WUs are finished? So we will know that this N=31172165 is minimal unless the pre-PrimeGrid processing of K=10223 failed to double check everything.

When we found the recent SoB prime, did we let the remaining smaller work units on the same K value finish?

Any workunits that went out to users were allowed to complete. They were both smaller and larger than the prime. There are still around 20 of them that haven't completed yet.

Will that mean that for K=10223, every N below 31172165 will eventually be checked, once those twenty outstanding WUs are finished? So we will know that this N=31172165 is minimal unless the pre-PrimeGrid processing of K=10223 failed to double check everything.

(I assume PrimeGrid sends out the WUs in order of increasing N.)

Or will there be a small number of N values below 31172165 that will never be tested, for example because the user abandoned it voluntarily and at that time you already knew internally that the K=10223 series was being retired?

/JeppeSN

I suspect we're going to wait for the new LLR before starting the double check, so we might be starting the double check somewhat later than expected. I'll let you know as events develop, but there's no dates I can give you at this time.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

Feel free to continue discussion about new LLR version in LLR Version 3.8.18 released
____________
My stats

Effective immediately:

The new LLR version is now live for SoB. (It's v8.00 as far as BOINC task versions go.)

This means we can start the DC when we're ready.

It also means you can use app_config to easily configure SoB to run multi-threaded.

32-bit Macs are no longer supported. We've been unable to build the software such that it will work on 32 bit-Macs. The number of 32-bit macs currently running on primegrid (or at least successfully running) is a 1-digit number -- in ANY base. Our apologies to the owner of that computer, but we can not support that platform anymore.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

Might be a dumb question with an easy to find the answer. But does primegrid update automatically? aka if I run sob will it use 8.0 automatically? OR where is app_config?

I saw the "<cmdline>--nthreads" in the app_version. When I run SOB it uses a full core (25% of the CPU), can you please explain what will this multi-threading do? how many threads to use?

Well the app_config did the trick and SOB was running on all four cores, but then I looked on GPU-Z and both GPUs, 960 & 1060 were not doing too well, the once nice smooth bar graphs were now looking more like combs, the “PerfCap Reason” was showing “Util”, “GPU load” was fluctuating widely and even the “GPU Core Clock” was unstable.

I revert back from 378.78 to 378.66, it didn’t help, I switched SOB back to one core and everything went back to normal.

There goes my dream of 2+ days SOB, back to 9 days.

It's almost mind-boggling that the double check is almost up to where SoB was many years ago when I began participating in that particular project.
____________

It's almost mind-boggling that the double check is almost up to where SoB was many years ago when I began participating in that particular project.