View Single Post
Old 2021-02-13, 17:00   #8
VBCurtis
 
VBCurtis's Avatar
 
"Curtis"
Feb 2005
Riverside, CA

139316 Posts
Default

Quote:
Originally Posted by bur View Post
VBCurtis, yes, I'm using sr1sieve which was the fastest among the various srsieves for this task. Good advice to feed candidates from the sieve to LLR testing. I guess I would remove all those candidates that are faster to LLR than to sieve?

And a general question, sometimes the LLR task will have to be interrupted (updates, etc). Is there a better way to continue afterwards than manually checking lresults for progress and removing those numbers from the LLR input file? Can it somehow check automatically which numbers are already tested in lresults?
You don't pick up very much sieve speed by removing candidates- break off a chunk that tests in a reasonable time, something convenient for your manual labor. That is, you might sieve 100k to 4M, and then break off 100-150k for LLR while 150-4M keeps sieving. By the time you're up to 500k, you might break off 100k blocks instead- it doesn't matter a whole lot.

LLR maintains an .ini file that includes the line number it has tested. Don't edit the input file when restarting- it will always pick up where it left off.

LaurV seems to be comparing his idea to a plan that never breaks off small pieces when they're "ready" for LLR. I am confident that removing small candidates from the sieve when appropriate is much much faster than LaurV's splitting by N-range. He and I rarely disagree, and he will surely relish showing me I'm mistaken!
VBCurtis is offline   Reply With Quote