Thanks KEP!

I srfile'd -k -a factors.txt base138.abcd

Restarted sieving and P jumped significantly... from 5.4 million to 9.6 million per second!

Despite reading the help file and trying to get some other cores thrown in on the action, (sr2sieve readme file says to just add -t 2)
I couldn't get it to work.

I then did a sr2sieve -h and there was no mention of the -t switch to add child threads.

The readme file says the feature was implemented for versions 1.7 and higher..
I'm using sr2sieve 1.8.11

Anyways... Looks as if I'll just start sieving a different p range in a different directory to speed things up.

Good stuff.

Neo

The 70% rule of thumb is to time LLR for a candidate exponent 70% of the way from min to max of the exponents in your sieve. That gives the average test time. If you were planning to LLR the entire sieve file, it would be most efficient to sieve until the removal rate is equal to that testing rate.

However, as you point out, you do not plan to test the entire file- you plan to find a prime! Finding a prime does two things to alter the "what is the perfect sieve amount" calculation: (1) It removes tests you no longer need to complete, and (2) it speeds the sieve by about sqrt(8/7). Rather than try to calculate the odds of a prime or the expected value where you'll find your first prime, it's wise to just sieve to something deeper than the rate for the initial LLR tests, and alternate LLR with more sieving.

Also, the factors rate will not rise perfectly linearly- the estimate this far in advance is accurate perhaps only within 20%. So, somewhere in the 12 to 15T range would be a reasonable minimum to move to LLR for the first block of tests. Once LLR time jumps substantially, remove the tested candidates from the sieve, and sieve a few more T. The sieve will speed up by the sqrt of the fraction of the number of candidates you removed (just like it does when you prime a k and remove it). So, if you remove 10% of the tests, the sieve will run about sqrt (1.1) faster in T/day.

Edit: Finding a prime is likely to be for one of the heavier k's first, which would remove more than 1/8th of the tests from the sieve. So, the sieve would speed up by more than sqrt (8/7).

I want to thank [B]EVERYONE[/B] for their input and advice.

I now have two separate sr2 sieves going on the same base (R138) with different P ranges...

I have reconfigured my BIOS and have it computing at 4 ghz. (I had my i-5 downclocked to 3.2ghz due to AVX heat concerns). Now running at 4 ghz with a WRgenfer(OCL) task running on my 770gtx, and two sr2sieves.... temps stable at 68 degrees.

Now getting 12.3 million P per second per CORE!

I'm going to crush this R138 base! :)

Neo

[QUOTE=Neo;392786]
I'm going to crush this R138 base! :)
[/QUOTE]

Good plan! :smile:

372*138^103160-1 is prime! (220753 decimal digits, P = 11) Time : 665.765 sec.

1K down, 7K to go!

Neo

S130
 

Sierp Base = 130
Conjectured k = 1021537
Covering Set = 7, 31, 131, 541
Trivial Factors = k == 2 mod 3(3) and k == 42 mod 43(43)

Found Primes: 656253k's
Remaining: 5491k's - Tested to n=2.5K
Trivial Factor Eliminations: 356350k's
MOB Eliminations: 3439k's
GFN Eliminations: 3k's
k's in balance @ n=2.5K
PFGW used = 3.4.3 dated 2010/11/04
2944 primes found 2.5K-10K
2547k's remain @ n=10K

Results emailed - Base released

Reserving R121 to n=1M

S185 tested to n=1M (250k-1M)

nothing found

Results emailed - Base released

R147
 

R147 reserved to n=50K

reserving R123 and R160
n=250000 to 400000

R160
 

status update
R160, n=250000 - 300000 done
no prime
continuing
results emailed