It is a well known fact that some k's are just better than others for finding Proth Primes.

Some k's are easier to sieve, leading to a low tasks/prime ratio (k=607, 739, 395, 1307, 5387, ...)

Some k's just have a lot of primes, which means it is desirable to test them (k=165, 1023, 435, 975, 8499, 4257, 9867, ...)

And some k's just dont seem to produce much primes at all (k = 31, 47, 167, 1899, any k from SoB, ...)

(Above k's based mostly only on Primegrid's statistics)

((And some k's are just monsters! https://groups.yahoo.com/neo/groups/primenumbers/conversations/topics/9963))

Also we have the fact, that smaller k's are noticeably faster to test.

So I ask; would it be feasible/efficient to make the PPS project a little more focused some time in the future? We wouldnt keep testing the k's in SoB either (actually some old SoB k's apparently ARE in PPSE), so why should we spend our time and electricity on k's that dont are not efficient in finding primes? We would of course lose some of sieving work, although nothing stops us from testing the more undesirable k's at some later point if we want.

Currently since we are sieving PPS already to 9M, we would still have work left for years to come, even if we dont test every k.

Some discussion related to this topic was also in this topic: http://www.primegrid.com/forum_thread.php?id=8029.

What do you think? Currently we have 10 k's in PPS and 404 k's in PPSE with no primes. Average number of primes per k is 7.87 in PPS and 3.80 in PPSE.

It is a well known fact that some k's are just better than others for finding Proth Primes.

No, because after sieving all k's are equal.

Some k's just have a lot of primes, which means it is desirable to test them (k=165, 1023, 435, 975, 8499, 4257, 9867, ...)

They have also a lot of candidates. The ratio #primes/#candidates is constant for a fixed sieve limit.

I think it makes sense to search all odd k in parallel. Sure enough, some k will have more candidates after sieving, so we will spend relatively more time with them, but also find more primes there. That should be proportional to the effort spent. Yves already explained it better.

You could search only the k values with many candidates, but why not include the others, for a little extra work?

In the opposite direction, you could also search only the k values with few candidates, from the consideration that their primes are more "valuable" because in some sense they are rarer. In fact, this is what we do with SoB. Of course the disadvantage with this is that there are few candidates in each n interval (exponent interval), so the n value goes up really fast if you focus all your ressources on these k with few primes.

Also we have the fact, that smaller k's are noticeably faster to test.

Ah, I do not know so much about how these calculations are done, but one can learn from reading these threads.

What happens if we compare, as an example, k=6553 and k=6561, for similar values of n? Because 6553 is "rough" (it is a prime), while 6561, despite being slightly larger, is 3-smooth.

Is 6561*2^n + 1 in fact just as efficient af 3*2^n + 1?

Should we prefer smooth k and skip rough k?

/JeppeSN