Endlessly Running Jacobi error check on v29.3

emiller · 2017-11-10, 22:35

Ever since I upgraded to mprime v29.3, the program constantly loops through running Jacobi error check.

I managed to get mprime to perform my desired LL-type calculations for a short while, but eventually it reverts to this and remains stuck in this loop, constantly pushing out the expected completion date.

Is this a known bug?

GP2 · 2017-11-10, 22:55

Quote:

Originally Posted by emiller

Ever since I upgraded to mprime v29.3, the program constantly loops through running Jacobi error check.

It could be a bug in the Jacobi error check code, but it seems more likely that your machine is producing errors and the Jacobi code is working as intended.

Has this machine worked on other exponents, and have any of them been double-checked yet?

emiller · 2017-11-10, 22:57

It's actually occurring on two machines. Both have completed a number of now verified LL runs and both were running fine on v28 (can't remember the sub-version).

GP2 · 2017-11-10, 23:15

Quote:

Originally Posted by emiller

It's actually occurring on two machines. Both have completed a number of now verified LL runs and both were running fine on v28 (can't remember the sub-version).

Maybe run some torture tests from the menu, to rule out the possibility of your machines having developed a problem recently. It seems unlikely that two machines would do so simultaneously, but perhaps they are plugged into the same wall outlet and power has been glitchy lately?

Can you give some examples of output from the results.txt or prime.log files?

Are you willing to share what the exponents are? They might be close to an FFT size boundary. I could try running a double check or triple check to see if the problem is reproducible.

Prime95 · 2017-11-10, 23:19

Can you post the screen output (or email me)? Perhaps there is a bug in recovering from a failed Jacobi check.

In the meantime you can put "JacobiErrorCheck=0" in prime.txt.

emiller · 2017-11-11, 00:18

Quote:

Originally Posted by Prime95

Can you post the screen output (or email me)? Perhaps there is a bug in recovering from a failed Jacobi check.

In the meantime you can put "JacobiErrorCheck=0" in prime.txt.

I sent you a private message via this forum's interface.

Looking through my prime.log file, it seems my previous version was v28.10.

I had experienced this as soon as I updated to v29.3. I let things run for a while (days, maybe even weeks). It kept repeating the error check over and over again. I then decided to clear out some of my computer-specific files. This resulted in the checkout of new exponents, one for each machine, and I see now that after running for a few percent, things have returned to this endless check.

Prime95 · 2017-11-11, 02:07

Here is the key output from the log you sent me: "Passed. Time: 93923.444 sec."

This error check takes 30 seconds on my computer! Since these Jacobi checks are scheduled to run every 12 hours and your test takes over a day to complete, you will indeed have an infinite loop of Jacobi checks.

Can you look around for libgmp_10.dll on your machine and post the dates? My only guess right now is Windows is locating an older, slower version of libgmp. Others here may have other ideas as to what could cause this.

emiller · 2017-11-11, 02:42

I think you hit the nail on the head, Prime95.

This is a CentOS6 machine and I did some unholy things to get around the missing libgmp.so.10.

I see what I did is mentioned in GP2's nice clear post here here.

And in that post, he astutely points out:

Quote:

Unfortunately,
yum whatprovides /usr/lib64/libgmp.so.3
indicates that this is gmp-4.3.1-12.el6.x86_64, and the fast Jacobi symbol code was introduced into GMP with version 5.0.0, which means the Jacobi code will run very slowly, maybe a hundred times slower.

So I probably should just bite the bullet and upgrade to centOS7.

Prime95 · 2017-11-11, 04:28

Get version 29.4. I've included the libgmp library in that release.

GP2 · 2017-11-11, 07:06

Huh... in my previous message it didn't occur to me that the old Jacobi library function could actually take longer than twelve hours.

In the Prime95 code, the call should be conditional:

[CODE]
# if __GNU_MP_VERSION >= 5
jacobi_error_check()
#endif
[/CODE]

Edit: hmm... that's a compile-time check obviously... according to the manual, there's also the global constant

Code:

const char * const gmp_version

which is a null-terminated string of the form, e.g., "5.0.0" (or just, e.g., "4.2" for very old versions).

The fast Jacobi function was introduced in GMP version 5.0.0 according to this old mailing list post.

GP2 · 2017-11-14, 10:26

Quote:

Originally Posted by GP2

The fast Jacobi function was introduced in GMP version 5.0.0 according to this old mailing list post.

I misread the mailing list post that is linked above.

Version 5.0.0 still had the old (quadratic) code. It was actually GMP 5.1.0 that introduced the faster (subquadratic) code, see https://gmplib.org/gmp5.1.html or https://gmplib.org/list-archives/gmp...er/000036.html

2017-11-10, 22:35	#1
emiller Apr 2017 10₁₀ Posts	Endlessly Running Jacobi error check on v29.3 Ever since I upgraded to mprime v29.3, the program constantly loops through running Jacobi error check. I managed to get mprime to perform my desired LL-type calculations for a short while, but eventually it reverts to this and remains stuck in this loop, constantly pushing out the expected completion date. Is this a known bug?

2017-11-11, 07:06	#10
GP2 Sep 2003 13·199 Posts	Huh... in my previous message it didn't occur to me that the old Jacobi library function could actually take longer than twelve hours. In the Prime95 code, the call should be conditional: [CODE] # if __GNU_MP_VERSION >= 5 jacobi_error_check() #endif [/CODE] Edit: hmm... that's a compile-time check obviously... according to the manual, there's also the global constant Code: const char * const gmp_version which is a null-terminated string of the form, e.g., "5.0.0" (or just, e.g., "4.2" for very old versions). The fast Jacobi function was introduced in GMP version 5.0.0 according to this old mailing list post. Last fiddled with by GP2 on 2017-11-11 at 07:24

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
29.4(64) Jacobi Error Worker 1 - this can't right	umbilicus	Software	3	2018-04-11 15:19
error during Jacobi check on 330,000,000+ exponent	evanh	Hardware	5	2018-02-20 03:46
LL testing: Jacobi symbol of the (interim or final) residue minus 2 as error check	GP2	Number Theory Discussion Group	33	2017-08-21 22:14
mprime ROUND OFF ERROR: Triple-check advised?	Bdot	Software	5	2012-12-22 22:34
Error in stats (Top LL Double-Check Producer)	moebius	PrimeNet	5	2010-11-09 23:19

2017-11-10, 22:57	#3
emiller Apr 2017 2·5 Posts	It's actually occurring on two machines. Both have completed a number of now verified LL runs and both were running fine on v28 (can't remember the sub-version).

2017-11-10, 23:19	#5
Prime95 P90 years forever! Aug 2002 Yeehaw, FL 2²×3²×13×17 Posts	Can you post the screen output (or email me)? Perhaps there is a bug in recovering from a failed Jacobi check. In the meantime you can put "JacobiErrorCheck=0" in prime.txt.

2017-11-11, 02:07	#7
Prime95 P90 years forever! Aug 2002 Yeehaw, FL 7956₁₀ Posts	Here is the key output from the log you sent me: "Passed. Time: 93923.444 sec." This error check takes 30 seconds on my computer! Since these Jacobi checks are scheduled to run every 12 hours and your test takes over a day to complete, you will indeed have an infinite loop of Jacobi checks. Can you look around for libgmp_10.dll on your machine and post the dates? My only guess right now is Windows is locating an older, slower version of libgmp. Others here may have other ideas as to what could cause this.

2017-11-11, 04:28	#9
Prime95 P90 years forever! Aug 2002 Yeehaw, FL 2²×3²×13×17 Posts	Get version 29.4. I've included the libgmp library in that release.