I've just created two new manual sieving projects. We've been looking at how well sieved we are for GFN32768, GFN65536 and GFN131072 since those are likely to start as BOINC projects once the OCL/OCL2/OCL3 client has been written and tested. GFN32768 isn't bad off at all, but GFN65536 and GFN131072 are very undersieved given the OCL3 max b.

GFN65536 and GFN131072 are the current sieving priority.

At those n levels, you should run 4 copies of gfnsvcuda for 65536 and 3 copies for 131072. At least that's what's optimal on my machine. And be aggressive with the b values. I'm using b11 because b12 starts to generate driver timeouts on my card. Experiment and see what the best overall P/day is that you can get. The program reports it, just give it 15-30 seconds for the number to stablize after starting the program (or an additional copy of the program). Alternatively, you could run one thread of this sieving while the GPU is busy with something else and see how that works out.

Sieving is removing candidates over 100x faster than they can be checked with genefer. Those need to be sieved now and will probably keep being sieved even after we start testing with genefer. I'll be removing candidates already loaded as sieving comes in.

The more these are sieved, the sooner we can start looking for primes. Now is the time to try manual sieving if you haven't before.

A few preliminary tests on my Gtx 970 (OCed to 1510mhz). One thing to note is that GFN 65536 completely sucks CPU cycles. I could do GFN 2097152 and only use around 1~2% of CPU per task, while having GPU usage at around 90~95% all the times (with temperatures on the roof...). With this one, however, it eats an entire CPU core, with GPU barely being used and temps on the higher 40s lower 50s (depending on when usage spikes).

First, B sizes:

How high of a b value can we set for the sieve?
____________

How high of a b value can we set for the sieve?

Run the program with no arguments to get help on the parameters. B13 is the highest but on my GTX 570, using B13 crashes the driver with a warning that the card took too long to return a result (or something like that). It's been a while, but I'm pretty sure it also kills GFNSvCUDA too. I find it better to run lower B values and either run multiple sieves simulaneously or run on B9 while simultaneously running genefer under BOINC.

As a general rule, use a tool which monitors GPU usage (bundled with video card or freeware GPU-Z) and run many copies of sieve, simultaneously playing with B-values, to get GPU usage close to 100%. 2 copies are minimal required value - the program is written in straightforward single-threaded way: when CPU is working, GPU is idle, and vice versa. I have to run 4 copies at B11 (GFN65536) to feed even middle-class GTX750TI at rate close to maximum, but yet not max. So I'm also running PPR12M sieve to pickup remaining GPU time (which appears to be about 25% :-( ). Even at 4xB11 screen lag is so big that system is unusable, thanks it's a dedicated cruncher. Lesser B values will avoid lag but decrease overall performance in my tests.

65536 nearly at 10000. Will it stop then with no more reservations, deemed as optimal?

65536 nearly at 10000. Will it stop then with no more reservations, deemed as optimal?

No. While we're using the OCL3 transform, the optimal sieving point is somewhere around 50,000P (50E). At the moment it's almost five times faster to remove candidates by sieving than it is by running two OCL3 tests per candidate.

With the GFN challenge finishing in 5 days, you may want to post some notices to entice some GPU users to switch to manual sieving. While they won't find primes sieving, they will eliminate candidates 400X faster @ n=22 than running a GFN-WR.

Poor AMD users, cant even do sieving...

I hope it's okay to sort of necro this thread instead of creating a new one.

Just wanted to share that while I haven't played around with the b values yet, for my GTX 1060 6GB the sweet spot in simultaneous sieving instances for GFN 16 seems to be 6-7. After that the increase in P/day plateaus or might even decrease. P/day maxed out that way is ~33-33.5; with 1 instance it's 12.9.

I have also tried it with a GTX 750 Ti, up to 3 instances, which yields 11.7 P/day as opposed to 8.2 for one.

For GFN 19 (1060) it's closer to 4 instances at once. (~45 P/day; 35.2 with 1 instance).

In terms of credit/sec, GFN 16 appears to be the best choice if you max it out that way, though it's pretty annoying to set up this many Command Prompts and all those low-GFN sieves demand a lot of CPU power as well.

I hadn't even considered combining different n values. I'll definitely give this a try.

Just tried 1x GFN 22 b=11 along with 1x GFN 16 b=8. About 71 and 8.6P/day, respectively. Already far more efficient than just piling GFN 16 sieves on top of each other without upping the b values. Still, probably a lot of room for tweaking and improvement.

hah, everytime I think I got something figured out on this site...

I haven't yet tried two instances of GFN22, since I figured a single one almost maxes out my GPU anyway.

Currently running 1x GFN22 (~53 P/day) and 3x GFN16 (10.2 P/day each) on the same card, all with b = 11. That amounts to about 5.64 credits per second, if you care about that sort of thing (that's more efficient than PPS sieve by 0.2 on my 1060 6GB, I suppose I could push that value with further instances of GFN16 or who knows what; btw, 7x GFN16 with b = 7 was about 3.32).

So far the setup seems like a good compromise between crunching and still being able to use my computer without going crazy with the lag.

GFN22 is so massively undersieved that I can't believe that people run GFN22, when manual GFN22 sieving eliminates candidates almost 1,000 times faster now.