To find out which numbers are actually checked on my computer, I had a look into the _cmd files. They contain something like

To add to JeppeSN's correct answer: the second file is a sieve file following the "ABCD" format which is used (for example) by the program OpenPFGW. The full documentation for ABCD (as well as two related formats, ABC and ABC2) is included with OpenPFGW; you can find a download link via google.

The short explanation is that it encodes a very long list of numbers of the form 3*2^a-1, where "a" starts at 25,000,034 and then increments by each of the numbers you see below. (There are gaps because we already have factors for some of these numbers.) The 321 sieve program will determine whether any of these numbers are divisible by a prime between 52,830,560,000,000,000 and 52,830,570,000,000,000; if it finds any, it will report the factors back to the server. We will later get to skip the primality test for 3*2^a-1 for that value of a, since we will already know it's composite.

If you are exceptionally observant, you may notice that the ABCD file actually has another line that looks like the first, a little over halfway down. This is for numbers of the form 3*2^a+1 (instead of -1). We are currently sieving both forms for 25,000,000 <= a < 50,000,000.

Thanks for your answers, that helped a lot.

I looked up sieving and found the sieve of Eratosthenes, so I thought 321 Sieve meant the computer was doing that, i.e. crossing out numbers in a given range until only the prime remained.

On my computer the 321 sieving finds factors within every 40 to 45th WU, which is probably a general average. According to preferences 321 LLR WUs take 2515 mins on average and 321 sieve WUs take 81 mins on average.

At first glance this seems a waste of time, since 42.5 times 81 mins is 3442.5 mins. But I think I read somewhere each successful sieve WU removes 2 LLR WUs. In which case sieving saves a lot of CPU time.

Why is it 2 prime candidates, because it sieves for both 3*2^a + 1 and - 1?


And if that is so, wouldn't it make sense to at first offer 321 sieving only, until it doesn't make sense anymore in respect to CPU time and only then begin to hand out LLR prime test WUs?

Why is it 2 prime candidates, because it sieves for both 3*2^a + 1 and - 1?

And if that is so, wouldn't it make sense to at first offer 321 sieving only, until it doesn't make sense anymore in respect to CPU time and only then begin to hand out LLR prime test WUs?

It's not two candidates. It's just that two people have to test each candidate, and sieving avoids both of those tests.

The sieve WU is doubled checked to prevent eliminating one extra WU or one less WU.
LLR WUs check one candidate at a time. Sieving eliminates the obviously composite candidates so that the LLR WUs don't include them.
About the average, the deeper sieving goes, the less candidates are found. But 321 SV isn't going deeper quickly, so your situation is just random luck.
____________
My lucky number is 6219*2^3374198+1

To be honest, I still don't understand why one sieving WU eliminates two LLR WUs. I thought all WUs were doublechecked to rule out errors in calculation, isn't that true for sieving?

But 321 SV isn't going deeper quickly, so your situation is just random luck.

So here's the tl;dr:
A good and deep sieve is crucial for a prime search. But how deep is too deep? This question isn't suitable for 321 SV for now, but we're coming close in around 2 years.
321 SV is getting deeper and deeper slowly with every task, but the rate should be slow and unnoticeable, your case was pure luck. Really. I have about 41 tasks per factor, which constantly moves up and down. Possibly your next task will contain a factor, reducing the 1:65 rate to around 1:56 (just a random number, don't take this seriously).
Because 321 SV was closed around 2012 last time, the admins decided to reopen it in Mar 2019. (could it be that they wanted to fill the gap left by GCW SV closing?) This new sieve is sieving everything from the current leading edge to 50M. If a factor is found for a specific candidate, it's automatically removed from the candidates.

To be honest, I still don't understand why one sieving WU eliminates two LLR WUs. I thought all WUs were doublechecked to rule out errors in calculation, isn't that true for sieving?

As far as I know, most 321 sieve WUs, nowadays, find no factors. But a WU that does find one or more factors, will mean we can save one or more huge LLR WUs.

Do you have stats for the whole subproject?

The range p from 52 peta to 53 peta is now done, and we see in stats_321_sieve.php that 1049 factors were found. Is that reliable?

In the task quoted, a range in p from 52.83056 peta to 52.83057 peta was covered. That is one 100'000th of the length of the range 52 peta to 53 peta. In the ABCD file (sieveinput), the minus form (3*2^$a-1) was given. The exponent n (called $a in that file) started from 25'000'034 and was incremented by "delta n" values given on each of the lines following.

Is there more than one _cmd file per task? Is there more than one ABCD/sieveinput file per task? For example, one with the +1 form? What was the total number of WUs in the interval p = 52 peta ... 53 peta?

To clarify:

If one factor is found every n sieve tasks, then it takes n sieve taks to eliminate 1 LLR task?

Is that correct?


Average CPU time for LLR tasks is 2575 minutes. Average CPU time for sieving tasks is 79 minutes. An LLR task takes 32 times as long.

So it would seem that any n < 32 would make sieving inefficient. But it isn't, as Ravi explained because we sieve for LLRs that will take 10 times as long.

Though I feel you'd have to take into account that computational power will increase and once LLR reaches those ranges, it won't be a factor of 10 anymore.

Possibly your next task will contain a factor, reducing the 1:65 rate to around 1:56 (just a random number, don't take this seriously).

Yes sir, the stats are here.

To clarify:

If one factor is found every n sieve tasks, then it takes n sieve taks to eliminate 1 LLR task?

Is that correct?


Average CPU time for LLR tasks is 2575 minutes. Average CPU time for sieving tasks is 79 minutes. An LLR task takes 32 times as long.

So it would seem that any n < 32 would make sieving inefficient. But it isn't, as Ravi explained because we sieve for LLRs that will take 10 times as long.

Though I feel you'd have to take into account that computational power will increase and once LLR reaches those ranges, it won't be a factor of 10 anymore.

All of that seems correct to me. One thing we expect in the future, is running primality tests of 321 candidates on GPU (rather than CPU). /JeppeSN