Bases 251-500 reservations/statuses/primes

[gd_barnes]

S428 with CK=10 is complete to n=25K; only k=8 remains; highest prime 4*428^14+1; base released.

[Batalov]

Just in case R471 suddenly dies, I am running R470.
There are 2 k remaining at n=12K: 83, 137. Will take it to 25K.

[KEP]

In order to gain some CPU efficiency, I'm going to reserve R383 to n=100K aswell. This means following:

I'll pause sieving of S383 at p=1300G and now I'll start sieving the 9 k's from R383 to p=1300G and then I'll merge the 2 sievefiles into 1 and sieve them combined

Take care!

Kenneth

[Mathew]

R332 is complete to n=25K

Ck=38

k's remaining
k=18
k=28

k's removed from algebraic factors
k=36

Attached are the results.

[gd_barnes]

Originally Posted by KEP

In order to gain some CPU efficiency, I'm going to reserve R383 to n=100K aswell. This means following:

I'll pause sieving of S383 at p=1300G and now I'll start sieving the 9 k's from R383 to p=1300G and then I'll merge the 2 sievefiles into 1 and sieve them combined

Take care!

Kenneth

In this case, as a general rule, you will LOSE CPU efficiency by doing this but it is up to you. The reason why is that one side has so many more k's remaining than the other side: 50 k's vs. 9 k's. The guideline that I use is that if the ratio of # of k's remaining on one side is more than 3 times the # of k's remaining on the other side, then they should be sieved separately. I'll make an exception or two for very low # of k's remaining such as 4 vs. 1 or 7 vs. 2.

The reason why is that the optimum sieve depth on one side is likely to be so much different than the optimum sieve depth on the other side and/or the side with lesser k's will be held up quite a bit by the side with more k's.

Based on this, let me know if you wish to continue.

As a friendly reminder, for this likely 6 to 12 month effort, please be sure and back up your files at least once every 2-4 weeks.


Gary

[KEP]

@ Gary:

Based on your reply, I do not wish to continue, I really hadn't taken in to consideration that the difference in the amount of k's would have a somehow negative effect on the CPU efficiency. So as I write, I've cancelled further sieving, and thereby naturally also cancelled any R383 reservations.

Regarding the backup. I now every 4 weeks (the first weekend in the new month) do backup on an external HDD. So as you can see I also abandoned the backup on flash drives. So now in theory it should when all comes to all, still be possible to loose all work once again, but I seriously doubt it since data is now stored at least 2 places and as soon as S58 and S60 completes data will most likely be stored on the HDD of the Dual and the Quad core, plus on the external HDD. So one can say I learned my lesson at the last breakdown

Hope this got it all. I'm just wondering if the Primegrid people realize what you stated, since they have talked about merging the Riesel and Sierpinski sievefile, once the Riesel file is sieved just as deep as the Sierpinski file. Anyway that will be their headache and not ours, and maybe none of the 2 sievefiles will ever catch up on eachother, hence PG will avoid doing what started doing here

Take care

KEP

[gd_barnes]

Originally Posted by KEP

I'm just wondering if the Primegrid people realize what you stated, since they have talked about merging the Riesel and Sierpinski sievefile, once the Riesel file is sieved just as deep as the Sierpinski file. Anyway that will be their headache and not ours, and maybe none of the 2 sievefiles will ever catch up on eachother, hence PG will avoid doing what started doing here

KEP

The folks that run the PrimeGrid and SOB projects are quite sophisticated with many resources at their disposal. I'm fairly certain that they can merge the 2 files and have it make little differece because one side won't hold up the other, due to the fact that they can just sieve to virtually whatever depth that they want. It's remarkable how quickly that they can sieve. I read that they've already reached P=1P (1000T) for Riesel base 2.

The main reason that it becomes less efficient with fewer resources is that for far fewer k's, the optimum depth is frequently quite less. As an example, let's say that we were doing base 2. With our more limited resources, then one of the 2 sides would be held up for potentially a very long time getting all of the other side's k's sieved to a proper depth. It's not easy to tell which side would need to be sieved deeper for base 2 but I would guess it would be the Sierp side since it has been searched to n=~13M vs. n=~3M on the Riesel side, even though it's only 5 k's vs. 64 k's. But with almost unlimited resources, a project can afford to sieve to the deepest needed P-depth for all of the combined efforts that they are sieving at once.

Looked at in that manner and the fact that both sides are sieving all n<50M all of the time, it is technically more efficient to combine their sieves. The key is that they are not having one side "wait" on the other. The error that they could make is if they fail to start doing primality testing on the Riesel side while they are waiting to get it sieved to where the Sierp side is. At the much lower search depth of n=3M, even with more k's, the Riesel side should be able to start testing in the near future without having to wait to catch up to sieving on the Sierp side. That is where my two cents comes in to play here.

[KEP]

@ Gary's two cents

As far as I know, primality testing has begun for the Riesel side, and last I heard, PG according to Lennart were at p=1.7 P. On a side note, 2 k's have been pushed to n=5M, since they were the lowest weighed k's, weather or not they push the next low weight k to n=5M is not known to me, I'm just a bit puzzled as why they don't push a handfull at a time of the highweight k's to n=5M. That should statistically remove more k's and remove 3-5 % of all candidate n's. Anyway, I'm not participating at PG anymore, since I have no resources to spare. As always it was very educational reading and somewhat rather short reply this time

Take care

Kenneth

[MyDogBuster]

Reserving S342 as new to n=25K

[Mathew]

R318 is complete to n=25K
CK=144

3 k's remaining k=78,122,128

Attached are the results

[MyDogBuster]

Sierp Base 342
Conjectured k = 552
Covering Set = 5, 7, 149
Trivial Factors k == 10 mod 11(11) and k == 30 mod 31(31)

Found Primes: 473k's - File emailed

Remaining: 10k's - File emailed - Tested to n=25K

Trivial Factor Eliminations: 66k's

GFN Eliminations: 1K
342 (has a prime at n=31)

Base Released