CudaLucas Residual

[Madpoo]

Originally Posted by evoflash

Quick update to say all looks good. Dropped GPU clock to base setting and bottomed out the memory clock, no errors so far. Thanks for advice.

FYI, do yourself (and all of us) a favor and do at least one or two double-checks when doing a bunch of tweaking and testing where you're not entirely confident that it will produce an error free run.

Otherwise if you're doing first time checks and the system is a bit flaky, we won't know for years (and eventually you'll land on the "spewers of junk" list that I or perhaps some future version of me will generate based on "probably bad" machines)

I wouldn't bother mentioning it except you've already encountered the 0x2 residue loop, so just tweaking it enough to avoid that particular problem doesn't necessarily mean it's stable.

Ultimately though there are probably a lot of people who just run first-time checks and are blissfully unaware of any lurking problems, so it's good you were paying attention and saw an issue and dealt with it... kudos.

[evoflash]

Originally Posted by Madpoo

FYI, do yourself (and all of us) a favor and do at least one or two double-checks when doing a bunch of tweaking and testing where you're not entirely confident that it will produce an error free run.

Yeah, I think this is a great idea. I kicked off a first check, but is there any way I can save the progress on it, stop it, kick off a couple of double checks and then resume the initial check? Or alternatively do I consign the current work to the bin?

[kladner]

Originally Posted by evoflash

Yeah, I think this is a great idea. I kicked off a first check, but is there any way I can save the progress on it, stop it, kick off a couple of double checks and then resume the initial check? Or alternatively do I consign the current work to the bin?

Stop CUDALucas. Add the double-check(s) to the top of worktodo.txt, save, and restart the program. When the DCs finish, the first time check will resume where it left off.

[evoflash]

Originally Posted by kladner

Stop CUDALucas. Add the double-check(s) to the top of worktodo.txt, save, and restart the program. When the DCs finish, the first time check will resume where it left off.

I owe you beer.

[Dubslow]

Originally Posted by LaurV

+1. You just explained very well and in fewer words what I am trying to say for a long time.

Probably because basically the entire information of that post was stuff I've picked up from you Although it is of course very reasonable, and we have ample evidence that consumer GPUs have memory problems of some sort, I take it entirely on your word that they're deliberately shipped that way because it doesn't matter.

[kriesel]

Originally Posted by evoflash

Hello everyone, I'm starting out with CudaLucas, and ran a trial factor test to see if was working ok. So far so good. However when I ran a LL-double check I had residual of 0x0000000000000002 and received an error message at 100% which was confounding.

I put this down to high overclocking and restarted another check with a milder overclock that I use for stable gaming. I'm now getting patches of similar residue (see attachment), is this normal or am I wasting time/gpu watts?

Thanks for looking.

Lucas-Lehmer testing is particularly unforgiving of hardware error. As such, getting a configuration for which CUDALucas produces reliable results can also be useful for getting reliable results in other programs.

I didn't see identification of the GPU model you're using. Some have known issues with certain CUDALucas settings. You'll need to avoid those.

Standard operating procedure for bringing a new GPU card on line in CUDALucas ought be something like the following, in approximate time sequence:

Get the May 2.06beta. It includes code to check for systematic errors that most builds of 2.05.1 or earlier did not, on Windows at least.

Set up to run the following in sequence, with redirection of screen output to a text file.

Run -memtest on as many of the 25MB blocks as you can get it to run on. Not just 10 or 20 starting from the low address. For modern cards this may be well over 100 blocks. Try (nominal GB of the card, times 1024)/25 -4 as a starting point. Example: 3GB card, 3072/25-4= 122.88-4=~119. If it's too much, it will complain, reduce it by one and retry.

Check whether your GPU is a model known to have issues with 1024 threads. Or 32 threads. Some GPU models are not compatible with running with 1024 square threads. Yet -threadbench will run 1024 on these and often pick 1024 as the fastest. (That's probably because some call somewhere fails, so steps in the iterations get skipped.) See the bug and wish list at http://www.mersenneforum.org/showpos...postcount=2618

Run -fftbench over the range of lengths you expect to use in a year, expanding the start and end to the powers of two bracketing that range. For example, if you expect to run exponents from 40M double checks to 100M first time checks, that would be 2160k to 5600k fft length, so run 2048k-8192k. Check that the iteration times are generally increasing with the fft length. If longer fft lengths are yielding faster iteration times than at half the fft length, there's a problem that needs to be circumvented. Rerunning -fftbench after addressing the problem is recommended.

Run -threadbench. Check that the iteration times are fairly consistent within an fft length. Normal variations within an fft length are modest, often under 10 percent. If the iteration times show large differences, there's a problem that needs to be circumvented. That may involve using the mask bits to prevent use of 1024 or 32 thread counts. And rerunning -threadbench to create a good threads file.

Run it with " -r 1" option to check many residues through 10,000 iterations. Note that this test has limitations. It does not include any residue tests for fft lengths larger than 8192k currently.

(Optionally: do -fftbench, -threadbench, once for each CUDA level & bitness combination executable, saving between runs with file names to label them as to version, if you want to extract the last several percent of performance out of your GPU. Different CUDA levels & bitness benchmark fastest on a given card depending on the fftlength and GPU model.)

Running a successful test on a small Mersenne prime is recommended and success is encouraging, but it uses a small fft length and does _not_ mean other fft lengths will be error-free.

Running a double check successfully on a ~40M exponent that will contribute toward the overall GIMPS double check is good practice, and a match with another person's LL test residue is encouraging, but it does not necessarily mean larger exponents will also process correctly. Small or moderate exponents may run fine on a GPU card that has error-prone memory in the midrange or high end.

Now, if those prior tests were all passed, eventually, is time to consider running a first-time exponent checked out from the manual assignments page.

Remain alert to unexpected results of any kind. Faster than expected iteration time is a symptom of some problems. Repeating 64-bit residues having value 0x02, 0x00, or 0xfffffffffffffffd are also symptoms of problems.

It's probably a good idea to retest memory annually, and note any mismatching residues and any patterns. Hardware ages and eventually fails.

[LaurV]

wow! see? he only said he is paying in beer and see what a post you put!

[evoflash]

Originally Posted by kriesel

Lucas-Lehmer testing is particularly unforgiving of hardware error. As such, getting a configuration for which CUDALucas produces reliable results can also be useful for getting reliable results in other programs.

I didn't see identification of the GPU model you're using. Some have known issues with certain CUDALucas settings. You'll need to avoid those.

Standard operating procedure for bringing a new GPU card on line in CUDALucas ought be something like the following, in approximate time sequence:

Get the May 2.06beta. It includes code to check for systematic errors that most builds of 2.05.1 or earlier did not, on Windows at least.

Set up to run the following in sequence, with redirection of screen output to a text file.

Run -memtest on as many of the 25MB blocks as you can get it to run on. Not just 10 or 20 starting from the low address. For modern cards this may be well over 100 blocks. Try (nominal GB of the card, times 1024)/25 -4 as a starting point. Example: 3GB card, 3072/25-4= 122.88-4=~119. If it's too much, it will complain, reduce it by one and retry.

Check whether your GPU is a model known to have issues with 1024 threads. Or 32 threads. Some GPU models are not compatible with running with 1024 square threads. Yet -threadbench will run 1024 on these and often pick 1024 as the fastest. (That's probably because some call somewhere fails, so steps in the iterations get skipped.) See the bug and wish list at http://www.mersenneforum.org/showpos...postcount=2618

Run -fftbench over the range of lengths you expect to use in a year, expanding the start and end to the powers of two bracketing that range. For example, if you expect to run exponents from 40M double checks to 100M first time checks, that would be 2160k to 5600k fft length, so run 2048k-8192k. Check that the iteration times are generally increasing with the fft length. If longer fft lengths are yielding faster iteration times than at half the fft length, there's a problem that needs to be circumvented. Rerunning -fftbench after addressing the problem is recommended.

Run -threadbench. Check that the iteration times are fairly consistent within an fft length. Normal variations within an fft length are modest, often under 10 percent. If the iteration times show large differences, there's a problem that needs to be circumvented. That may involve using the mask bits to prevent use of 1024 or 32 thread counts. And rerunning -threadbench to create a good threads file.

Run it with " -r 1" option to check many residues through 10,000 iterations. Note that this test has limitations. It does not include any residue tests for fft lengths larger than 8192k currently.

(Optionally: do -fftbench, -threadbench, once for each CUDA level & bitness combination executable, saving between runs with file names to label them as to version, if you want to extract the last several percent of performance out of your GPU. Different CUDA levels & bitness benchmark fastest on a given card depending on the fftlength and GPU model.)

Running a successful test on a small Mersenne prime is recommended and success is encouraging, but it uses a small fft length and does _not_ mean other fft lengths will be error-free.

Running a double check successfully on a ~40M exponent that will contribute toward the overall GIMPS double check is good practice, and a match with another person's LL test residue is encouraging, but it does not necessarily mean larger exponents will also process correctly. Small or moderate exponents may run fine on a GPU card that has error-prone memory in the midrange or high end.

Now, if those prior tests were all passed, eventually, is time to consider running a first-time exponent checked out from the manual assignments page.

Remain alert to unexpected results of any kind. Faster than expected iteration time is a symptom of some problems. Repeating 64-bit residues having value 0x02, 0x00, or 0xfffffffffffffffd are also symptoms of problems.

It's probably a good idea to retest memory annually, and note any mismatching residues and any patterns. Hardware ages and eventually fails.

This should be a sticky post for first time users! Thank you.

After a couple of bad results with a 970, I've just plugged in a new 1080Ti and chugged a M4x,xxx,xxx double check successfully with downclocked memory, but will go back and follow up with those tests you have described.

Again, thank you.

[evoflash]

I should add, the 1080ti completed the check in ~1.5 days. The card is impressive.

[kriesel]

Originally Posted by evoflash

I should add, the 1080ti completed the check in ~1.5 days. The card is impressive.

You're welcome, and I come at these questions from the new user perspective because I am one in the gpu terrain.

I get 43.2M double checks through a GTX1070 in 32-36 hours. Your 1080Ti should be noticeably faster than a 1070. I've found scaling for run time is ~2.03 power of exponent for CUDALucas. There's about a 10% variation in iteration time among different CUDA level and bitness executables and my impression, having benchmarked a lot, before having done a rigorous comprehensive table is, the fastest executable changes a bit depending on fft length and GPU model combination. (I haven't checked yet how long it would take to get throughput payback on the time invested in benchmarking.)

[evoflash]

ah I should have added that was during otherwise casual use, not on all the time. For the next M8x,xxx,xxx number I'll see what the total time estimated is and report back.