Sieving for CRUS

My suggestion is to sieve some of the lowest difficulty bases as shown here:
http://www.noprimeleftbehind.net/cru...s-unproven.htm

Most of them will be 100-200k or 200k-400k. There are a lot of bases in that area that can more easily be proven or reduced to 1k or 2k remaining by BOINC.

Ok, can you tell me one base I could sieve, preferable sr1sieve or sr2sieve job, the limits to go to (about) and the time frame when you need it, and I can allocate some resources to it.

I'm sieving R347 (with its remaining k of 22) from n=200k to 400k. Not quite to P=1e12 yet, at which point I'll run a PRP test to get a feel for how far I need to sieve.

Using that list in the link that I posted above, the lowest difficulty bases are S428, S638, and S332. (Wombatman is doing R347.) I'd suggest starting with S428 for n=200k-400k.

Ok, sieving S428 for n>200k for a while, to see what's going on. Starting in one hour. Do you need factors file?

No

I have sieve file for S333 100K-250K, but sieve limit is only 1T. Will sieve deeply and send file to Gary.

Check for doubles

People should check when starting a sieve for a base and range to see if the other side (Riesel or Sierp) has the same base with the same range and sieve them together. Saves time and resources.

I'll be working on the 25K-100K range doing the doubles first.

We don't take sieving reservations so using this thread to give a general area of work would help out a bit.

R428 seems proven, which saves me of the troubles to learn how use srXsieve to sieve both sides in the same time...

S428 200k<n<1M sieved to 2e12 (it was faster than I expected). At this score, I have ~125 seconds per factor, which would mean ~1000 seconds per factor in the 200k-300k range. Some cllr test in the same cpu says about 1800-2000 seconds for one test.

There are <7500 candidates remaining in 200k<n<1M.

Question for the people knowing more about this subject: how much further should I go with sieving? And should I post the file here (~70kB) or send it to Gary?

---------------

In the same time I ran cllr in a different core for 8*428^n+1 for n to about 70k (continuing) - this is a doublecheck. Gary, do you need residue file for DC purposes?

--------------

I also ran low-sieving and cllr for all other k's (as there are only 9 all together) for n>=2, as I just didn't like those numbers being prime for n=1. This is for the category "futile work", but it still can be posted like a puzzle. I found primes for n higher than 1 for all of them, except 2 and 6, but 6 is eliminated by algebraic factorization, it seems that all of them are divisible by 7. So here the primes with higher n:
Now, the "puzzle" is that I didn't find any prime for k=2, although I sieved to 1T and I cllr it to n=69133 - still running.

(I am not so happy with the prime for k=4 also, as that is long known, and not a "new find", hehe, but I didn't do any action in that direction. )

One outcome from this futile playing with numbers is that I uncovered a small bug in cllr. My first sieving file was including 10*428^n+1 too, and it was sieving from n=0, therefore after srsieve kept 10*428^0+1 (which is prime) and eliminated all the other, so in the resulted sieved file (I stopped srsieve at 1e8 and continued with sr2sieve, then split and used sr1sieve for 2 and 8) - so in resulted file after first application of the srsieve, the 2*428^1+1 (=857, prime) followed after 10*428^0+1 (=11, also prime). In this very particular situation, cllr is testing the first one, and says it's prime, but is skipping the other one (i.e. misses the prime 857). Now I know this is a buggy situation, which will never happen in real life, but I wonder which other primes it can miss...

The k's remaining are low-weight enough that it's pretty likely the entire file will be tested; so this question is roughly equivalent to "what sieve depth minimizes the time to sieve plus the time to LLR the file?" In the short run, it's about finding the point where breaking off a piece (say, 200-300k) for LLR followed by more sieving on 300k-1M is better than just sieving more on the 200k-1M file.

If you test the 300k-1M sieve speed vs 200k-1M, you'll find that there's very little speed gain, meaning the 200-300 piece is, in a sense, getting sieved for free since we'll want the rest of the file sieved more. The heuristic I've found is that sieving until the sec/factor is at least double the LLR time for the smallest candidate is at the lower end of the right time to break off a piece.

However, you won't be LLRing it yourself- BOINC will. Just like the NFS@home matrix-solvers have NFS@ home make extra relations to make their matrix task shorter, there's nothing wrong with sieving less for BOINC than you might for yourself. For Riesel-3, I've been sending pieces of the sieve files to rebirther when sec/factor in sieve is the same as sec/test in LLR for a typical candidate in the piece.

30e12 would be a good spot to aim for for BOINC work, 50-75e12 for your own work.

Thanks for the reply, I found that, or something similar. I got the idea that I need to sieve to 3e13, that is what I need to know. In a sense, as you said, if some prime divides some s(n), the n is "random", so its chance to be in 300k-1M is 7/8 from the chance that n is in 200k-1M, and this is what the factor list shows: about one in 8 is in 200k-300k, and i get one every ~125 seconds, i.e. about 1000 seconds per factor.

Do you also need some XXL tests? I could give you a ready-to-go sieve file for S/R22 n=1.5M - 2M.

No, the main target is 25-100k

R347

Here's the sieved file (P=20e12) for R347 from n=200k-400k. There are 1679 candidates remaining.

Edit: I can go ahead and run base 373 as well. Is there an easy to run both the S373 and R373 at the same time? Or do I just run them concurrently with two instances of the siever?

Nevermind, got it sorted.

S428 status report: reached 12T, continuing to 30T as per Curtis' advice. In the same time I let cllr running for S428(8), it reached n=120k (this is a DC, but I don't think I will go to the full n=200k, as it is already getting very slow).

S/R373 and R610

R/S373 (k=18 and k=108, respectively) is on its way to P=20e12 and should finish Christmas Day.

R610 is heading to P=15e12, finishing on the 23rd.

Later tonight, I'll include a list of what is being worked on and who has what reserved for BOINC sieving in the first posting here. I'll also put a link to all completed files on the pages. Ian just sent me a large batch of bases sieved for n=25K-100K. That should keep BOINC busy for a while. :-)

Sweet! Thanks!

R610

Here's R610 for n=200k-400k, taken to P=15e12. 2284 candidates remaining.

I received a large batch of sieve files from Ian for n=25K-100K and 100K=200K. There is now a link to all of them on the pages. They are as follows:

S/R373

Here is S373 and R373 taken to P=20e12.

S428 k=8, up to n=1M sieved to 3e13 (or 30T). This means deep sieved. Finding a factor actually went much slower that the cllr went, at that depth. So, either my cllr is too fast, or my sr1sieve is too slow (read: I am doing something wrong, with the speeds I get I would stop somewhere at 15T-18T or so), but I still followed what people suggested, to go to 30T.

Additional in the zip, there is a double check of S428, as high as it could go during the sieving process in a parallel core, which I used for speed comparison (about n=180k), which may be needed by Gary or not.

Manual edit can be done on the sieve file to split the range, and eventually sieve the higher range higher (pun intended).

There is also a "sandbox" folder where I tried - without success - to find a reasonable prime for k=2 and k=4. Strange or not, there is no other prime to (about) n=110k (see the files), beside of the trivial known primes.

The file can be deleted by a mod, to save my quota of uploading space, when it was taken by the interesting parts (for Boinc and by Gary for DCs).

I may have goofed the sieve-depth estimate! If the file is 500k to 1M, the time per factor should be about twice as long as the time to LLR a 500k candidate. This accounts for the longer testing times as you proceed toward 1M. If the file goes lower than 500k, the usual heuristic is to find LLR time for a candidate about 2/3rds of the way through the file, and sieve until factor time matches that LLR time; so, if you have 100k to 1M, you'd measure LLR for a candidate around 700k. These estimates assume the same machine will sieve and LLR.

Sorry if my previous guesses caused you to oversieve- just think of the time you saved the BOINCers!