The Next Big Development for GIMPS - Page 26

aheeffer · 2020-08-10, 15:39

Quote:

Originally Posted by ATH

Use version 30.3 it has the required .dll's included:
https://mersenneforum.org/showthread.php?t=25823

or download gpuowl:
git clone https://github.com/preda/gpuowl
and use the python script: gpuowl/tools/upload.py
Usage:
./upload.py <GIMPSusername> <prooffilename>

Thanks, v. 30.3 did the job. It uploaded ten proofs for exponents between 100M and 201M for a total of 1,24 GB in about 30 minutes. One failed, but I noticed the file size is different from the original, so I copied and scheduled it again.

@kriesel: the link to the uploader.exe has expired

ATH · 2020-08-11, 16:42

Has any proof validation failed yet besides the proxy issues in the beginning?

If 100% of the proofs are validated for a long time, there is always the nagging suspicion of a bug somewhere instead of Gerbicz error checking catching all the hardware issues.

Prime95 · 2020-08-11, 17:14

Quote:

Originally Posted by ATH

Has any proof validation failed yet besides the proxy issues in the beginning?

4 have failed -- sort of.

3 failed because of a bug in parsing the proof file header (it read one byte too many if the first binary byte of data was an ASCII space, tab, or newline. 3 proofs were reprocessed and certified successfully.

1 failed yesterday when I uploaded a new server processor program but somehow built it with out-of-date sources? Sometimes this new-fangled Visual Studio 2019 does things I don't expect. Maybe I'm too old to easily get the hang of new things.... Anyway, it too was reprocessed and certified successfully.

storm5510 · 2020-08-11, 17:26

I have had three instances of the following today:

Quote:

Error getting number from proof header

All of these are on the same proof file which is still in the Prime95 folder. These occur on the line (screen) after "MD5." Each time, the hash is the same. I looked at the entry in the results.json.txt file. Nothing jumps out. M5664731 is here.

Prime95 · 2020-08-11, 18:40

What jumps out is version 30.3 build 1. Grab build 2.

storm5510 · 2020-08-11, 23:19

Quote:

Originally Posted by Prime95

What jumps out is version 30.3 build 1. Grab build 2.

Done. I was not paying attention to the updates and one got by. My apologies! I need to check here much more frequently as other updates may come along.

Build 2 sent to two proof's on their way. They are undersized, about 5.5 MB instead of just short of 12. The two exponents are 5664731 and 5820589.

kriesel · 2020-08-14, 14:28

Some of those CERT assignments are heavier than others. https://www.mersenne.org/report_expo...3003647&full=1 is the largest I've seen yet, at 19.35GhzD (elapsed time 13.83 hours on an i5-1035G1, 1300796 iterations corresponding to power 8).
More typical is for ~107M at 1.73GhzD, ~1.24 hours on the same cpu as above. Lowest was for ~1.75M, at 0.0007 GhzD or ~2 seconds. (Of 164 to date.)
Scaling by p^2.1 (for constant proof-power), a 999M cert would be ~194. GhzD; 6 days on the i5-1035g1, or weeks on some of my hardware.
(Save of interrupted work, Gerbicz error check or two Jacobi symbol checks, and resume of interrupted work are additional, and depend on the specifics of interrupted work and the system on which they occur.)

evoflash · 2020-09-03, 09:23

Wow! I ran double check M83646581 on new (2nd hand) cpu 7700K that had overtemp issue overnight - 3 hardware errors detected. Previously I'd abandon the test, fix the PC and restart. I let this one run as it stated excellent confidence and hey presto it correctly verified the initial PRP test.

Is this a new level of robustness/error repair in the code?

kruoli · 2020-09-03, 10:27

Yes, the PRP code with Gerbicz error checking is much more robust than anything before with LL.

Prime95 · 2020-09-03, 15:14

Quote:

Originally Posted by evoflash

Wow! I ran double check M83646581 on new (2nd hand) cpu 7700K that had overtemp issue overnight - 3 hardware errors detected. Previously I'd abandon the test, fix the PC and restart. I let this one run as it stated excellent confidence and hey presto it correctly verified the initial PRP test.

Is this a new level of robustness/error repair in the code?

Upgrade to build 4 and you'll be able to upload the proof that you did the work. This will make us even more confident in your double-check.

evoflash · 2020-09-03, 21:13

Quote:

Originally Posted by Prime95

Upgrade to build 4 and you'll be able to upload the proof that you did the work. This will make us even more confident in your double-check.

Thanks for the tip. I have just installed build 4 and it's now sending. Great stuff.

2020-08-14, 14:28	#282
kriesel "TF79LL86GIMPS96gpu17" Mar 2017 US midwest 3×23×71 Posts	Some of those CERT assignments are heavier than others. https://www.mersenne.org/report_expo...3003647&full=1 is the largest I've seen yet, at 19.35GhzD (elapsed time 13.83 hours on an i5-1035G1, 1300796 iterations corresponding to power 8). More typical is for ~107M at 1.73GhzD, ~1.24 hours on the same cpu as above. Lowest was for ~1.75M, at 0.0007 GhzD or ~2 seconds. (Of 164 to date.) Scaling by p^2.1 (for constant proof-power), a 999M cert would be ~194. GhzD; 6 days on the i5-1035g1, or weeks on some of my hardware. (Save of interrupted work, Gerbicz error check or two Jacobi symbol checks, and resume of interrupted work are additional, and depend on the specifics of interrupted work and the system on which they occur.) Last fiddled with by kriesel on 2020-08-14 at 14:41

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Your help wanted - Let's buy GIMPS a KNL development system!	airsquirrels	Hardware	313	2019-10-29 22:51
Is GMP-ECM still under active development?	mathwiz	GMP-ECM	0	2019-05-15 01:06
LLR 3.8.6 Development version	Jean Penné	Software	0	2011-06-16 20:05
LLR 3.8.5 Development version	Jean Penné	Software	6	2011-04-28 06:21
LLR 3.8.4 development version is available!	Jean Penné	Software	4	2010-11-14 17:32

2020-08-11, 16:42	#277
ATH Einyen Dec 2003 Denmark 2²×757 Posts	Has any proof validation failed yet besides the proxy issues in the beginning? If 100% of the proofs are validated for a long time, there is always the nagging suspicion of a bug somewhere instead of Gerbicz error checking catching all the hardware issues.

2020-08-11, 18:40	#280
Prime95 P90 years forever! Aug 2002 Yeehaw, FL 3×31×79 Posts	What jumps out is version 30.3 build 1. Grab build 2.

2020-09-03, 09:23	#283
evoflash Dec 2012 23 Posts	Wow! I ran double check M83646581 on new (2nd hand) cpu 7700K that had overtemp issue overnight - 3 hardware errors detected. Previously I'd abandon the test, fix the PC and restart. I let this one run as it stated excellent confidence and hey presto it correctly verified the initial PRP test. Is this a new level of robustness/error repair in the code?

2020-09-03, 10:27	#284
kruoli "Oliver" Sep 2017 Porta Westfalica, DE 433 Posts	Yes, the PRP code with Gerbicz error checking is much more robust than anything before with LL.