Sierp base 3 reservations/statuses/primes

[gd_barnes]

Good luck Kenneth! :-) That would be excellent to finish by the end of the year!

[rogue]

FYI, I expect to complete sieving for S3 for k<40G to 8e11 by the end of July.

[KEP]

It's been almost 3 months since last status. S3, k=1G to k=13G is running 100% CPU ressources on the 12 core Xeon.

Of 36,902 k's remaining 4,717 is primed (12.78% primed)
Of 36,682,989 tests remaining, 30,683,179 is untested (number includes tests saved due to primed k) (83.64% remains)

Min N over range 57729
Max N over range 58524

There is 12 ranges running 1G each, using StopOnPrimedK=1 and UseCharCode=1.

Regards

Kenneth

[rogue]

Originally Posted by KEP

It's been almost 3 months since last status. S3, k=1G to k=13G is running 100% CPU ressources on the 12 core Xeon.

Of 36,902 k's remaining 4,717 is primed (12.78% primed)
Of 36,682,989 tests remaining, 30,683,179 is untested (number includes tests saved due to primed k) (83.64% remains)

Min N over range 57729
Max N over range 58524

Are your files sorted by n, then by k or are they sorted by k then by n?

[KEP]

Originally Posted by rogue

Are your files sorted by n, then by k or are they sorted by k then by n?

They are sorted by ascending n - that is why there is more tests showing untested than actually remains. With the settings in LLR, I reduce the manual work to almost nothing after completion.

[rogue]

Originally Posted by KEP

They are sorted by ascending n - that is why there is more tests showing untested than actually remains. With the settings in LLR, I reduce the manual work to almost nothing after completion.

I use the -fP option with srsieve2 to generate a file by ascending k then ascending n. It allows you to compute an expected end date much more accurately. So if you have processed 40% of the file, then you know that you are closely 40% of the time thru processing the file. If sorted by n first, 40% of the file might only be 20% of the time. Also, if something weird happens where llr doesn't know where to restart a file if it was terminated accidentally, you can use the list of primes/prps to edit out the input file. For example if the last prime found was for k = 93847564, then you can delete all rows from your input file for k <= 93847564 before restarting llr, which is easy to do since it is sorted by ascending k.

[KEP]

Originally Posted by rogue

I use the -fP option with srsieve2 to generate a file by ascending k then ascending n. It allows you to compute an expected end date much more accurately. So if you have processed 40% of the file, then you know that you are closely 40% of the time thru processing the file. If sorted by n first, 40% of the file might only be 20% of the time. Also, if something weird happens where llr doesn't know where to restart a file if it was terminated accidentally, you can use the list of primes/prps to edit out the input file. For example if the last prime found was for k = 93847564, then you can delete all rows from your input file for k <= 93847564 before restarting llr, which is easy to do since it is sorted by ascending k.

After my current completion of R3, I'm just not going down the ascending k ascending n testing anymore. It was a nightmare to sort the k's due to the sort function of windows cmd, did not sort properly when told to sort by n, it did correct sort ascending n, but the k's were not sorted in ascending order. So for the sake of my own manual intervention and to keep the risk of copy paste and manual errors as low as possible, I'm not going back that road at all, if in any way avoidable. But your points are correct and using ascending k sorting makes it easier to say at least how much work does remain untested. Thanks for the suggestion