20200218, 23:54  #1871 
"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest
C89_{16} Posts 
Yes. Fixed previously. The modern extrasensitivetouchpad 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 doubletap 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/tdp/1362239 Last fiddled with by kriesel on 20200219 at 00:18 
20200219, 20:36  #1872 
∂^{2}ω=0
Sep 2002
República de California
10100110111110_{2} Posts 
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 periteration ROE checking, the Gerbicz check should still catch residue corruption by excessive ROE in some output during the current Gcheck 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 midrun by ctrlc and restarting with the needed FFTlength commandline 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 gpuOwlset upper limit for a given FFT length hits an ROEerrordisguisedasGerbiczcheckerror and causes the run to switch to the nextlarger FFT length as a result? Last fiddled with by ewmayer on 20200219 at 21:09 
20200219, 21:17  #1873  
∂^{2}ω=0
Sep 2002
República de California
29BE_{16} Posts 
Quote:
So this seems like a straightforward code fiddle  instead of just barfing, when a run hits a repeatable Gcheck 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 nextlarger 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 carrychain length used, but I see a user option "carry longshort". 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 force5120K run started with "0 errors", then quickly cycled through 1,2,3,4 errors as it hit repeatable Gcheck errors due to a roundoffcorrupted 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 Gcheck error count as 1 error? Last fiddled with by ewmayer on 20200219 at 21:33 

20200220, 09:47  #1874  
"Mihai Preda"
Apr 2015
2·11·41 Posts 
Quote:
About carry size, long provides better accuracy but it's so much slower that it's practically never used nowadays. Basically moving to the nextupper FFT size might well be faster than the long carry. The default is always short carry. About the number of errors (2 vs 4), this is a bit tricky: a savefile is only ever created with valid data that passed the check "right now". The number of errors is incremented in RAM, but can only be written as part of a valid savefile. What probably happened in you case is this: an error is hit (count becomes 1), backtrack, does a check earlier than the error point that passes OK and this saves (with count 1), again hits the error point, backtracks, and eventually hits 3 consecutive errors and stops. Anyway improvements clearly can be made; but I'd like to identify the changes that have a clear behavior, a clear benefit, and not excessive cost before proceeding. 

20200220, 19:34  #1875  
∂^{2}ω=0
Sep 2002
República de California
2×3×13×137 Posts 
Quote:
Quote:
You're right regarding the slowness of carry long for your code  current expo running at 5632K at 755 us/iter. Halting and restarting with fft 5120K as I did yesterday cuts timing to 708 us, but is more or less guaranteed to abort with Gcheck error resulting from incorrectlyrounded output due to excessive ROE. Using 'fft 5120K carry long' might be safe in terms of ROE, but blows up the persquaring time to 960 us, so I'm back to the default 5632K here. Quote:
Quote:
Last fiddled with by ewmayer on 20200220 at 19:54 

20200220, 22:27  #1876  
"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest
6211_{8} Posts 
Quote:


20200221, 03:19  #1877 
"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest
3,209 Posts 
gpuowlwin v6.11148gfc93773 build
Here it is, fresh from h and no more testing than that. This commit should have the P1 fft size fix mentioned in https://mersenneforum.org/showpost.p...postcount=1868
Last fiddled with by kriesel on 20200221 at 03:20 
Thread Tools  
Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
mfakto: an OpenCL program for Mersenne prefactoring  Bdot  GPU Computing  1583  20200220 18:25 
GPUOWL AMD Windows OpenCL issues  xx005fs  GPU Computing  0  20190726 21:37 
Primality testing nonMersennes  lukerichards  Software  8  20180124 22:30 
Mersenne trial division implementation  mathPuzzles  Math  8  20170421 07:21 
Testing Mersenne cofactors for primality?  CRGreathouse  Computer Science & Computational Number Theory  18  20130608 19:12 