Sieving for CRUS

[MisterBitcoin]

I can provide the following bases for deeper sieving:


R709, 100K-250K

R711, 100K-250K
R798, 200K-500K
R806, 400K-1M
R1017, 250K-500K

[gd_barnes]

Originally Posted by MisterBitcoin

I can provide the following bases for deeper sieving:


R709, 100K-250K

R711, 100K-250K
R798, 200K-500K
R806, 400K-1M
R1017, 250K-500K

The deeper sieve depth that Pepi is referring to should only be used for n>1M. It would be a waste of resources to sieve smaller tests to such a depth.

It's no big deal if Pepi has Yoyo sieve these. But I suggest sieving them to their usual depth that they have always done, not the deeper depth.

[MisterBitcoin]

Originally Posted by gd_barnes

The deeper sieve depth that Pepi is referring to should only be used for n>1M. It would be a waste of resources to sieve smaller tests to such a depth.

It's no big deal if Pepi has Yoyo sieve these. But I suggest sieving them to their usual depth that they have always done, not the deeper depth.

Those are sieved up to 25e9 and one up to 50e9 and would recommend to sieve them deeper with yoyo@home.

50e12 sounds like a fair value for them.

[pepi37]

All is OK, I will made and sent to YOYO all sieves: for him it is irrelevant how deep is initial sieve.

[MisterBitcoin]

Goal 4 is an large amount of work.
I am not sure if srsieve2 can handle that large k. (srsieve could, but its very slow)

Other than that i am willing to help sieving on R3.



According to the Remain side "only" 35G-55G is left, or do you already have an sieve file for that range?




Other than that i dont thing i cant contribute that much this year. Main focus for me is NF@home.

[rogue]

Originally Posted by MisterBitcoin

Goal 4 is an large amount of work.
I am not sure if srsieve2 can handle that large k. (srsieve could, but its very slow)

Other than that i am willing to help sieving on R3.

According to the Remain side "only" 35G-55G is left, or do you already have an sieve file for that range?

Other than that i dont thing i cant contribute that much this year. Main focus for me is NF@home.

I would be surprised if srsieve2 could not. Assuming it does, due to the most recent changes in srsieve2, I cannot think of any case where srsieve2 is slower than srsieve.

I'll give it a spin and let you know what happens.

[rogue]

Seems to work fine with all remaining k between 25G and 60G:

srsieve2 -P1e9 -n5e4 -N1e5 -sr3.in -W6
srsieve2 v1.3, a program to find factors of k*b^n+c numbers for fixed b and variable k and n
(kp) Sequence has algebraic factorization: 46908629056*3^n-1 -> (216584^2)*3^n-1
(kp) Sequence 46908629056*3^n-1 has 25001 terms removed due to algebraic factors of the form 216584*3^(n/2)-1
Sieving with generic logic
Sieve started: 3 < p < 1e9 with 4944273883 terms (50000 < n < 100000, k*3^n+c) (expecting 4682160754 factors)
  p=1213, 0.656 p/sec, 4560646177 factors found at 262.5K f/sec (last 1 min), 0.0% done. ETC 2097-09-06 18:43
Sieving with generic logic
Split 98884 base 3 sequences into 98884 base 3^1 sequences.
  p=1571749, 304.1 p/sec, 4758573825 factors found at 2.019K f/sec (last 1 min), 0.2% done. ETC 2021-02-24 07:05

The ETC is is off because of factor validation. As the factor density decreases, the ETC will become more accurate as the p/sec will increase.

srsieve2 with 6 threads is taking about 2G of memory. The ABCD file is less than 700M

I will let this run longer, but I'm not certain that I will finish the sieving to 1e9.

[KEP]

Originally Posted by MisterBitcoin

According to the Remain side "only" 35G-55G is left, or do you already have an sieve file for that range?

Yes, there is a sievefile ready, made by Gary and seems to have been taken up partially or fully by BOINC. Currently srbase is working on 25G-35G, as I remember it, from n>50K to n=100K.

I fooled around recently, when getting familiar with srsieve2, trying to sieve ALL k's remaining for S3 - none of them failed to sieve. To be honest I would be surprised, if any of our current confined amount of conjectures has k's that fail to be able to be sieved - the only possible conjecture for reaching a limitation of k, could and would only be R280 - but it is not gonna be started for many years, so it is - if it should be a concern - not really a current concern

[rebirther]

Originally Posted by rogue

Seems to work fine with all remaining k between 25G and 60G:

srsieve2 -P1e9 -n5e4 -N1e5 -sr3.in -W6
srsieve2 v1.3, a program to find factors of k*b^n+c numbers for fixed b and variable k and n
(kp) Sequence has algebraic factorization: 46908629056*3^n-1 -> (216584^2)*3^n-1
(kp) Sequence 46908629056*3^n-1 has 25001 terms removed due to algebraic factors of the form 216584*3^(n/2)-1
Sieving with generic logic
Sieve started: 3 < p < 1e9 with 4944273883 terms (50000 < n < 100000, k*3^n+c) (expecting 4682160754 factors)
  p=1213, 0.656 p/sec, 4560646177 factors found at 262.5K f/sec (last 1 min), 0.0% done. ETC 2097-09-06 18:43
Sieving with generic logic
Split 98884 base 3 sequences into 98884 base 3^1 sequences.
  p=1571749, 304.1 p/sec, 4758573825 factors found at 2.019K f/sec (last 1 min), 0.2% done. ETC 2021-02-24 07:05

The ETC is is off because of factor validation. As the factor density decreases, the ETC will become more accurate as the p/sec will increase.

srsieve2 with 6 threads is taking about 2G of memory. The ABCD file is less than 700M

I will let this run longer, but I'm not certain that I will finish the sieving to 1e9.

I have issues with the boinc output file. With -W16 it has stopped at 32M of 1G and with -W30 it had a massive slowdown (sieving around 320k factors), the outputfile was 2.5GB and had 162M lines. I have 128GB so memory should not be a problem.

[rogue]

Originally Posted by rebirther

I have issues with the boinc output file. With -W16 it has stopped at 32M of 1G and with -W30 it had a massive slowdown (sieving around 320k factors), the outputfile was 2.5GB and had 162M lines. I have 128GB so memory should not be a problem.

This occurs because the program is waiting for all workers to finish before it can be guaranteed there are no unsieved gaps below the p in the output file.

There are two options. One use a smaller -w so that the threads have less work per iteration. The other is to rename the output file from the previous checkpoint and hit ^C twice.

[gd_barnes]

R3 is already fully sieved by me. Otherwise I would not have made it a goal.

I used srsieve. It worked well. It was easy enough to split the sieve into multiple k-ranges and then combine them all at the end.

Running multiple instances of srsieve seemed much faster than srsieve2.