The reason I mentioned this is because IT IS *NOT* a good idea to run PrimeGrid GPU tasks with an overclocked system. You will get a LOT of errors. Games, benchmarks, other projects may work fine, but on PrimeGrid, your cards get put to the ultimate test. I would not recommend running any projects overclocked or more than the tiniest bit overclocked... or watch the errors begin to pile up.

The reason I mentioned this is because IT IS *NOT* a good idea to run PrimeGrid GPU tasks with an overclocked system. You will get a LOT of errors. Games, benchmarks, other projects may work fine, but on PrimeGrid, your cards get put to the ultimate test. I would not recommend running any projects overclocked or more than the tiniest bit overclocked... or watch the errors begin to pile up.

I've actually had a lot of success with the gfn sieve app, it seems to be a lot more resilient to OCs than actual GFN or AP prime tests. I can usually clock higher, and I'd often have crashes in games / benchmarks way before having errors in gfn-sv.

The reason I mentioned this is because IT IS *NOT* a good idea to run PrimeGrid GPU tasks with an overclocked system. You will get a LOT of errors. Games, benchmarks, other projects may work fine, but on PrimeGrid, your cards get put to the ultimate test. I would not recommend running any projects overclocked or more than the tiniest bit overclocked... or watch the errors begin to pile up.

I've actually had a lot of success with the gfn sieve app, it seems to be a lot more resilient to OCs than actual GFN or AP prime tests. I can usually clock higher, and I'd often have crashes in games / benchmarks way before having errors in gfn-sv.

The problem is there's no double checking with that sieving. If it has errors, you would never know about the errors, and we could be losing factors without ever knowing anything was wrong.

I thought you double check the factors at the time the submitted factor files are processed? So bad factors aren't accepted?

Also, currently only 40% of GFN-22 manual sieve factors are NEW. 60% were already sieved out by a previous P range. So losing a factor due to error, is no big loss. It's likely to be removed already, or will be removed by a future P range sieve. Or a GFN-22 will check to see if it's prime.

Every factor submitted is tested. Any factor that doesn't divide its specified candidate is dropped. I get maybe 10-15 of those a year. As far as missing factors, there are factors found per 1P sieved and candidates removed per 1P sieved on the sieving stats graphs. There's also code to find gaps within factor files, but it certainly won't catch single factors missing. While I don't look at those sieving density numbers every day, any unusually low numbers will eventually be investigated. I have been known to rerun ranges that I find suspicious, but I think it's only twice that I actually found something. The smaller the range, the more the chances of legitimately deviating from the averages.

Something that frequently finds factors is that I have code that reruns the end of every submitted file. While the number in the checkpoint file is usually some internal value, you can also put a factor value in there and the program will start from that factor. I just had a range two hours ago that was missing the last 1.2P. Since I wasn't in a hurry at that time, I finished the range rather than go back to the siever to do it. Two days ago a different factor file was missing 5P. Video driver crashes cause the sieving program to stop and there could be other causes as well.

For those that have been around a while, you'll remember when there were versions of the nVidia drivers that gave completely wrong factors on sieving. Those were caught immediately because of all the testing code here. The BOINC genefer validator will still reject any results computed with those drivers.

hrrrmm, I've been sieving with a 200 core OC on some of my NVIDIA cards and 100 on some of my AMDs (and downclocking memory whenever possible). It adds a noticable amount of P/day to each and seemed stable.

Should I stop doing that on account of potentially missed factors?
____________
Long live the sievers.

+ Encyclopaedia Metallum: The Metal Archives +

This is about RTX 2080 but anyway for those wondering how it is doing.

gfnsvocl_w64_2G.exe with default settings on GFN22 - about 177P/day.
B8 - 350P/day
B9 - 495P/day
B10 - 680P/day
B11 - 720P/day
B12 - 730P/day
B13 - 765P/day, not nice to work with.
____________
My stats

When someone overclocks way too much, it's obvious to me. I send those users PMs telling them that either their card is dying or they should cut down on the overclocking. When I tested overclocking the OpenCL sieving program, it seemed like it kept performing OK until it (and the video driver) died completely. FWIW I don't normally overclock my cards and this was a one-time test on a single one of my GPUs. But I think the bottom line is that if you're overclocking now, you're probably safe to keep doing so. Please do not keep pushing OCing higher until I complain about it. Instead run a 1P range that you've run before and compare the results. Be aware that the individual factors don't always come out in the exact same order.

What is the power draw? How many watts does it suck down?

When I tested overclocking the OpenCL sieving program, it seemed like it kept performing OK until it (and the video driver) died completely.

Please do not keep pushing OCing higher until I complain about it.

Instead run a 1P range that you've run before and compare the results. Be aware that the individual factors don't always come out in the exact same order.