mersenneforum.org  

Go Back   mersenneforum.org > Great Internet Mersenne Prime Search > Hardware > GPU Computing

Reply
 
Thread Tools
Old 2020-02-18, 23:54   #1871
kriesel
 
kriesel's Avatar
 
"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

C7E16 Posts
Default

Quote:
Originally Posted by axn View Post
You did notice the extra 0, right?
Yes. Fixed previously. The modern extra-sensitive-touchpad laptops are creating havoc with my interactive use, and in this case, after highlighting 60 for overwrite with 55, I didn't notice that it had changed to just the 6 highlighted, apparently. I learned touch typing around 1970 when most of the typewriters were manual and it was an honor to get to use an IBM Selectric powered typewriter with the flying spinning ball head. One of the things that I remember being taught is thumbs over the space bar. Unfortunately that puts them hovering over the often too sensitive touchpad on a laptop, giving all manner of unintended cursor moves. Normally on my old 17' display laptop I would double-tap the upper left corner and it would indicate touchpad off with a tiny LED there, but that laptop is out of action currently. Touchpad is now turned off by the Windows 10 control on this laptop, which I'm using to access the rest; the wireless mouse is SO much better behaved.

I have one laptop that has a touch screen also, and developed the "bubbles" problem where it senses its own display bezel as touches! It became increasingly sensitive, to the point where it made interactive use almost impossible. Disabling the touch screen device was what made it usable again. https://forums.lenovo.com/t5/Lenovo-...e/td-p/1362239

Last fiddled with by kriesel on 2020-02-19 at 00:18
kriesel is offline   Reply With Quote
Old 2020-02-19, 20:36   #1872
ewmayer
2ω=0
 
ewmayer's Avatar
 
Sep 2002
Rep├║blica de California

246608 Posts
Default

Just started in on a batch of p's ~= 96.4M on my Radeon 7 ... that is close to he upper limit of what can be done @5120K using Prime95 and Mlucas, but I notice gpuOwl more conservatively defaults to 5632K. Without per-iteration ROE checking, the Gerbicz check should still catch residue corruption by excessive ROE in some output during the current G-check interval, so I'd like to test that out.

Is there a way to force it to try 5120K, and if so can this be done mid-run by ctrl-c and restarting with the needed FFT-length command-line flag?

EDIT: The readme is your friend... just killed current run, restarted with '-fft 5120K' ... that has proceeded for another million iterations, so far, so good. Has anyone reading this seen a case where an exponent close to the gpuOwl-set upper limit for a given FFT length hits an ROE-error-disguised-as-Gerbicz-check-error and causes the run to switch to the next-larger FFT length as a result?

Last fiddled with by ewmayer on 2020-02-19 at 21:09
ewmayer is online now   Reply With Quote
Old 2020-02-19, 21:17   #1873
ewmayer
2ω=0
 
ewmayer's Avatar
 
Sep 2002
Rep├║blica de California

101001101100002 Posts
Default

Quote:
Originally Posted by ewmayer View Post
EDIT: The readme is your friend... just killed current run, restarted with '-fft 5120K' ... that has proceeded for another million iterations, so far, so good. Has anyone reading this seen a case where an exponent close to the gpuOwl-set upper limit for a given FFT length hits an ROE-error-disguised-as-Gerbicz-check-error and causes the run to switch to the next-larger FFT length as a result?
Once again in answer to my own question - predictably, literally seconds after posting my above edit, my run @5120K hit its first G-check error. The code retried 3 more times, then after the 4th attempt, quit with "3 sequential errors, will stop."

So this seems like a straightforward code fiddle - instead of just barfing, when a run hits a repeatable G-check error as mine did, if the exponent is close to or above the default limit for the FFT length in question, simply switch to the next-larger FFT length.

One related question regarding running near the exponent limit for a given FFT length - the OpenCL args echoed by the program on runstart do not say anything re. the carry-chain length used, but I see a user option "-carry long|short". Which choice gives better accuracy, and how can one tell what the default choice is for a given exponent and FFT length?

And another followup question regarding the "n errors" field output at each checkpoint - my force-5120K run started with "0 errors", then quickly cycled through 1,2,3,4 errors as it hit repeatable G-check errors due to a roundoff-corrupted residue. It then aborted. On restart sans the -fft flag it again defaulted to 5632K and is happily chugging along, but the errors field is now stuck at "2 errors". How did we go from 4 to 2? And shouldn't a repeatable G-check error count as 1 error?

Last fiddled with by ewmayer on 2020-02-19 at 21:33
ewmayer is online now   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
mfakto: an OpenCL program for Mersenne prefactoring Bdot GPU Computing 1580 2020-02-18 21:11
GPUOWL AMD Windows OpenCL issues xx005fs GPU Computing 0 2019-07-26 21:37
Primality testing non-Mersennes lukerichards Software 8 2018-01-24 22:30
Mersenne trial division implementation mathPuzzles Math 8 2017-04-21 07:21
Testing Mersenne cofactors for primality? CRGreathouse Computer Science & Computational Number Theory 18 2013-06-08 19:12

All times are UTC. The time now is 21:50.

Wed Feb 19 21:50:58 UTC 2020 up 19 days, 16:22, 1 user, load averages: 2.23, 2.22, 2.39

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.