Bug with LLR !!

T.Rex · 2010-01-05, 13:56

Hi,

I've found a bug with LLR (Lucas-Lehmer-Riesel) version 3.7.2 .

Given a specific Wagstaff exponent, I get a different residue each time I test it on Intel HW (Core2 and Xeon)
Double-check on Intel HW over about 1200 other exponents is OK.
Verification of this exponent on Opteron is OK (2 identical residues for 2 checks).

So, it seems that some range of exponents may lead to a wrong random Residue.

Jean Penné does not answer to emails since a while (I think is 75 and he may have stopped reading emails. I'll try to get news from him).

Since LLR makes use of prime95 core code, there is also the possibility that the bug is common with prime95 (at least with an old version of Prime95).

I need help from LLR and Prime95 experts.

Who can help ?

Thanks,

Tony

ldesnogu · 2010-01-05, 15:43

Sorry if this is a stupid idea: what about picking the sources, replace gwnum with its latest source, recompile and test again? That could at least make a gwnum bug less probable.

rogue · 2010-01-05, 15:50

Quote:

Originally Posted by T.Rex

Hi,

I've found a bug with LLR (Lucas-Lehmer-Riesel) version 3.7.2 .

Given a specific Wagstaff exponent, I get a different residue each time I test it on Intel HW (Core2 and Xeon)
Double-check on Intel HW over about 1200 other exponents is OK.
Verification of this exponent on Opteron is OK (2 identical residues for 2 checks).

So, it seems that some range of exponents may lead to a wrong random Residue.

Jean Penné does not answer to emails since a while (I think is 75 and he may have stopped reading emails. I'll try to get news from him).

Since LLR makes use of prime95 core code, there is also the possibility that the bug is common with prime95 (at least with an old version of Prime95).

I need help from LLR and Prime95 experts.

Who can help ?

Thanks,

Tony

Run the test with PFGW. If you get consistent residues, then the problem is with LLR. If not, then it is with gwnum.

diep · 2010-01-05, 15:57

Quote:

Originally Posted by rogue

Run the test with PFGW. If you get consistent residues, then the problem is with LLR. If not, then it is with gwnum.

Could be bug in CPU also that pops up. There is like 250 bugs found in core2's later on, bios cannot fix them all.

ldesnogu · 2010-01-05, 16:26

Quote:

Originally Posted by diep

Could be bug in CPU also that pops up. There is like 250 bugs found in core2's later on, bios cannot fix them all.

That's not impossible, but the probability is extremely low: after all did Prime95 hit any CPU computation bug? And LLR is using the same code base.

Also aren't most of the 250 bugs (BTW I only found about 100 in Intel doc) very specific to system? I mean I'm not aware of a bug such as the infamous DIV bug found a few years ago.

henryzz · 2010-01-05, 16:37

Is there a way to forcefully make the FFT length higher to hopefully get a correct result?

kar_bon · 2010-01-05, 16:38

Maybe another reason:

The EXE for V3.7.2 is from 2008-09-13 and from V3.7.1c from 2009-05-17!

I've send Yves in December 2008 an issue about residues with V3.7.1c with small n-values,
the example was a twin: 7945335*2^5426+/-1

With the 'old' version i got this for example:
7945335*2^5426+1 is not prime. Proth RES64: D634636A24EF9A52

After his corrections it's all ok with:
7945335*2^5426-1 is prime!
7945335*2^5426+1 is prime!

So there's a difference in the LLR versions: V3.7.2 is not corrected to that issue i think!

T.Rex · 2010-01-05, 16:46

Quote:

Originally Posted by ldesnogu

Sorry if this is a stupid idea: what about picking the sources, replace gwnum with its latest source, recompile and test again? That could at least make a gwnum bug less probable.

Not stupid at all. However, I know nothing about how LLR is built. There is gwnum in source259.zip of Prime95. But there are so many files... Aren't there people who already know how to upgrade LLR with a fresher version of gwnum ?
Tony

T.Rex · 2010-01-05, 16:49

Quote:

Originally Posted by rogue

Run the test with PFGW. If you get consistent residues, then the problem is with LLR. If not, then it is with gwnum.

How do you ask PFGW to output a residue ?
Tony

rogue · 2010-01-05, 16:56

Quote:

Originally Posted by T.Rex

How do you ask PFGW to output a residue ?
Tony

If you are not using the -t switch, it will always output the residue, but the base 2 residues with PFGW will not match those from LLR. Other bases will match. My point was that if you can run base 2 tests with PFGW and get consistent residues, then the issue is with LLR and not gwnum.

Quote:

Originally Posted by henryzz

Is there a way to forcefully make the FFT length higher to hopefully get a correct result?

Use -a1 or -a2 with PFGW

T.Rex · 2010-01-05, 16:57

Quote:

Originally Posted by diep

Could be bug in CPU also that pops up. There is like 250 bugs found in core2's later on, bios cannot fix them all.

The bug also appears on Intel Xeon. I will test ASAP on Nehalem.
Tony

2010-01-05, 13:56	#1
T.Rex Feb 2004 France 2×457 Posts	Bug with LLR !! Hi, I've found a bug with LLR (Lucas-Lehmer-Riesel) version 3.7.2 . Given a specific Wagstaff exponent, I get a different residue each time I test it on Intel HW (Core2 and Xeon) Double-check on Intel HW over about 1200 other exponents is OK. Verification of this exponent on Opteron is OK (2 identical residues for 2 checks). So, it seems that some range of exponents may lead to a wrong random Residue. Jean Penné does not answer to emails since a while (I think is 75 and he may have stopped reading emails. I'll try to get news from him). Since LLR makes use of prime95 core code, there is also the possibility that the bug is common with prime95 (at least with an old version of Prime95). I need help from LLR and Prime95 experts. Who can help ? Thanks, Tony

2010-01-05, 15:43	#2
ldesnogu Jan 2008 France 3·181 Posts	Sorry if this is a stupid idea: what about picking the sources, replace gwnum with its latest source, recompile and test again? That could at least make a gwnum bug less probable.

2010-01-05, 16:37	#6
henryzz Just call me Henry "David" Sep 2007 Cambridge (GMT/BST) 2×41×71 Posts	Is there a way to forcefully make the FFT length higher to hopefully get a correct result?

2010-01-05, 16:38	#7
kar_bon Mar 2006 Germany 2·1,439 Posts	Maybe another reason: The EXE for V3.7.2 is from 2008-09-13 and from V3.7.1c from 2009-05-17! I've send Yves in December 2008 an issue about residues with V3.7.1c with small n-values, the example was a twin: 79453352^5426+/-1 With the 'old' version i got this for example: 79453352^5426+1 is not prime. Proth RES64: D634636A24EF9A52 After his corrections it's all ok with: 79453352^5426-1 is prime! 79453352^5426+1 is prime! So there's a difference in the LLR versions: V3.7.2 is not corrected to that issue i think!