After some discussion with Louie Helm at Seventeen or Bust, we are going to change the way work is divided between SoB and PG. After a transition period, PrimeGrid will be crunching only k=10223 and k=67607, while SoB will crunch only the other 4 k's. Each project will be entirely responsible for its own k's.

Why? Well, if we never find another SoB prime, things will work fine the way are now. But if we take a more optimistic view and assume we WILL find a prime, there's a problem: We'll have wasted an immense amount of crunching. This change will correct that problem.

Currently, PrimeGrid is crunching in the n=27M range, and SoB is crunching in the 29M range. If PrimeGrid finds a prime in the 27M range, every test that SoB did in the 28M and 29M ranges in that k will have been wasted effort! Likewise, once we finish the 27M tests and move on to 31M tests, if SoB finds a prime, everything PrimeGrid will have tested at 31M in that k will have been wasted.

By dividing the work by k we avoid this problem.

One thing that doesn't change: if PrimeGrid finds a prime, both PG and SoB share the project credit for the discovery.

The current plan is for us to complete the current 27M and upcoming 31M tests in all the k's and then only crunch 10223 and 67607. At some point we will probably do some double checking of earlier SoB work that was not yet double checked. Details will become available later.

(For those that are curious and more attuned to the details, the residues that SoB uses are not the same as what PrimeGrid normally uses. This makes double checks more complicated. However, our LLR program can do the same test and produce the same residue as SoB's software if we use the correct command line arguments. However, SoB's older software has completely incompatible residues, so hopefully there aren't a lot of those that need double checking.)
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

Agree, it seems to be a more effective way, also in term of no longer reserving ranges etc.

Is it expected (or desirable) that both PG and SoB maintaine about the same progress for each k?

(for sure, once a k is eliminated, we might need to reconsider splitting other k's).

Is sieving done up to 50M?
If there is need for more, I assume PG will do more sieving and provide remaining candidates to SoB.
____________
My stats

Is it expected (or desirable) that both PG and SoB maintaine about the same progress for each k?

Desirable? Not sure. We've punched certain k's higher for some reason in the past in conjectures. In the end, it doesn't matter much what order you search the k's because to solve the conjecture you need to do all those tests anyway. In a sense, you could treat each k as an individual project.

The only thing binding them together is sieving. We're done with sieving up to 50M, so that's not a factor anymore.

It's almost certain that PG and SoB will not advance at the same speed, so one of us will definitely be at a higher n,

(for sure, once a k is eliminated, we might need to reconsider splitting other k's).

Is sieving done up to 50M?

What does this mean in time and deadline?

It looks like the Seventeen or Bust project stopped crunching k=10223 and k=67607 at a little over n=29,183,000. Candidates for those two k values from 29.183M<n<31M have now been added to the system and will start going out soon. All work goes out in n,k order so those will run before the 31M range. Thanks to KEP for pointing this out.