Bug with LLR !!
 

Hi,

I've found a bug with [URL="http://pagesperso-orange.fr/jean.penne/index2.html"]LLR[/URL] (Lucas-Lehmer-Riesel) version 3.7.2 . :help:

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

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.

[QUOTE=T.Rex;200937]Hi,

I've found a bug with [URL="http://pagesperso-orange.fr/jean.penne/index2.html"]LLR[/URL] (Lucas-Lehmer-Riesel) version 3.7.2 . :help:

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[/QUOTE]

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

[QUOTE=rogue;200943]Run the test with PFGW. If you get consistent residues, then the problem is with LLR. If not, then it is with gwnum.[/QUOTE]

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.

[quote=diep;200944]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.[/quote]
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.

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

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!

[QUOTE=ldesnogu;200942]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.[/QUOTE]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

[QUOTE=rogue;200943]Run the test with PFGW. If you get consistent residues, then the problem is with LLR. If not, then it is with gwnum.[/QUOTE]How do you ask PFGW to output a residue ?
Tony

[QUOTE=T.Rex;200952]How do you ask PFGW to output a residue ?
Tony[/QUOTE]

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=henryzz;200949]Is there a way to forcefully make the FFT length higher to hopefully get a correct result?[/QUOTE]

Use -a1 or -a2 with PFGW

[QUOTE=diep;200944]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.[/QUOTE]The bug also appears on Intel Xeon. I will test ASAP on Nehalem.
Tony